Re: Problems with draft

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

>>>>      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;
>>> [uncompressed]
>>> 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.
> Except for section 4, which describes the transport-level mangling of
> compression, padding and encryption, all mention of "payload" in the
> specs refer to the uncompressed, unencrypted, unpadded payloads.

Good - but how can one tell that?  Indeed, I would be tempted to read
section 5's (not 4's - section 4 is "Connection Setup")

     byte[n1]  payload; n1 = packet_length - padding_length - 1
[...]
      payload
         The useful contents of the packet.  If compression has been
         negotiated, this field is compressed.  Initially, compression
         MUST be "none".

as being the _definition_ of "payload" for the rest of the draft, by
which interpretation "payload" would be unencrypted but compressed.

>> 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.
> And conciseness is also important;

True enough.

> If you really think this needs additional clarification, please write
> the text you want and the wg should consider it.  I'd recommend
> rewording section 4 so that it doesn't use the word "payload" to
> refer to a string that sometimes contain the payload in compressed
> form.

Here's a patch against transport-17.  In the interests of keeping the
diff small, I made no attempt to re-fill paragraphs or move page
breaks; I assume the draft was generated from a master file in some
other format, and presumably the changes need to be made to that other
format and the distributed draft file regenerated.

--- transport-17.txt	Wed Nov 26 21:04:37 2003
+++ new-transport-17.txt	Sun Nov 30 17:35:37 2003
@@ -265,7 +265,7 @@
 
      uint32    packet_length
      byte      padding_length
-     byte[n1]  payload; n1 = packet_length - padding_length - 1
+     byte[n1]  compressed-payload; n1 = packet_length - padding_length - 1
      byte[n2]  random padding; n2 = padding_length
      byte[m]   mac (message authentication code); m = mac_length
 
@@ -285,14 +285,15 @@
       padding_length
          Length of padding (bytes).
 
-      payload
+      compressed-payload
          The useful contents of the packet.  If compression has been
          negotiated, this field is compressed.  Initially, compression
-         MUST be "none".
+         MUST be "none".  (When "payload" is used without adjective
+         elsewhere, it refers to the uncompressed form.)
 
       random padding
          Arbitrary-length padding, such that the total length of
-         (packet_length || padding_length || payload || padding) is a
+         (packet_length || padding_length || compressed-payload || padding) is a
          multiple of the cipher block size or 8, whichever is larger.
          There MUST be at least four bytes of padding.  The padding
          SHOULD consist of random bytes.  The maximum amount of padding
@@ -305,7 +306,7 @@
 
 
    Note that length of the concatenation of packet length, padding
-   length, payload, and padding MUST be a multiple of the cipher block
+   length, compressed-payload, and padding MUST be a multiple of the cipher block
    size or 8, whichever is larger.  This constraint MUST be enforced
    even when using stream ciphers.  Note that the packet length field is
    also encrypted, and processing it requires special care when sending
@@ -318,9 +319,9 @@
 
 5.1 Maximum Packet Length
 
-   All implementations MUST be able to process packets with uncompressed
+   All implementations MUST be able to process packets with (uncompressed)
    payload length of 32768 bytes or less and total packet size of 35000
-   bytes or less (including length, padding length, payload, padding,
+   bytes or less (including length, padding length, compressed-payload, padding,
    and MAC.). The maximum of 35000 bytes is an arbitrary chosen value
    larger than uncompressed size. Implementations SHOULD support longer
    packets, where they might be needed, e.g. if an implementation wants
@@ -362,7 +363,7 @@
    current block is not a stored block, one or more empty blocks are
    added after the current block to ensure that there are at least 8
    bits counting from the start of the end-of-block code of the current
-   block to the end of the packet payload.
+   block to the end of the (compressed) packet payload.
 
    Additional methods may be defined as specified in [SSH-ARCH].
 
@@ -370,7 +371,7 @@
 
    An encryption algorithm and a key will be negotiated during the key
    exchange.  When encryption is in effect, the packet length, padding
-   length, payload and padding fields of each packet MUST be encrypted
+   length, compressed-payload and padding fields of each packet MUST be encrypted
    with the given algorithm.
 
    The encrypted data in all packets sent in one direction SHOULD be
@@ -491,7 +492,7 @@
      mac = MAC(key, sequence_number || unencrypted_packet)
 
    where unencrypted_packet is the entire packet without MAC (the length
-   fields, payload and padding), and sequence_number is an implicit
+   fields, compressed-payload and padding), and sequence_number is an implicit
    packet sequence number represented as uint32.  The sequence number is
    initialized to zero for the first packet, and is incremented after
    every packet (regardless of whether encryption or MAC is in use).  It

/~\ 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