Re: Problems with draft

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> In transport-17, section 6.2 writes of a "shared secret K", treating
>> it as an opaque blob which is passed as part of a HASH argument.
>> But section 7 writes of K as a large integer.  It's not entirely
>> clear how the one is converted into the other;
>    o  Initial IV client to server: HASH(K || H || "A" || session_id)
>       (Here K is encoded as mpint and "A" as byte and session_id as raw
>       data."A" means the single character A, ASCII 65).

> So I don't think the core drafts need to changed at this point.

Thanks.  I must have missed that.

>> Also, section 7 writes
>>    The hash H is computed as the HASH hash of [...]
>>      string    I_C, the payload of the client's SSH_MSG_KEXINIT
>>      string    I_S, the payload of the server's SSH_MSG_KEXINIT
>> It is not clear whether these are compressed or uncompressed;
> It refers to the payload after the transport layer transformations,
> i.e. after decryption and decompression, with padding removed.
> Again, I don't think a change in the core drafts is necessary.

Perhaps.  I think I disagree, though; I don't see how someone
implementing from scratch is supposed to know, from the drafts, that
I_C and I_S are the decompressed forms.  (Decrypted makes sense, on
reflection, since if a block cipher is in use, then before decryption
the beginning of the payload is generally mixed with the length
values.)

I still think less ambiguity on each point would be good.  This is,
after all, supposed to be a standard, so clarity is a Good Thing.  Is
there some high overhead associated with changing the drafts or
something?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B