openssh bugs - Jun 2025 - [Bug 3839] New: Is OpenSSH violating RFC4253 section 6

https://bugzilla.mindrot.org/show_bug.cgi?id=3839

            Bug ID: 3839
           Summary: Is OpenSSH violating RFC4253 section 6
           Product: Portable OpenSSH
           Version: 10.0p2
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: nicolas.baranger at 3xo.fr

Created attachment 3884
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3884&action=edit
SSH_MSG_NEWKEYS captured frame while rekey-ing

Currently working on Wireshark / TShark SSH dissector (decryptor) and
adding Post-Quantum algorithms and REKEY support, I was inspecting
frames and I discover that in case of a REKEY event, the
SSH_MSG_NEWKEYS send by the client seems to violate RFC4253 section 6: 

I was using mlkem768x25519-sha256 as algorithm and chacha20-poly1305 as
Cipher (stream AEAD Cipher)

Here is the NEWKEY frame OpenSSH sent after the second SSH_MSG_KEXINIT
and SSH_MSG_ECDH_REPLY:

After decryption, here is the SSH part of the frame:
00 00 00 08 06 15 cb 83 fd 7e 37 ab

Let break it down: 

00 00 00 08 : Length prefix (value 8) --> length 4 bytes
06 : padding length value: 6 bytes of padding --> length 1 byte
15 : effective payload of length 1, value decimal 21 (SSH_MSG_NEWKEYS)
--> length 1 byte
cb 83 fd 7e 37 ab: padding string of 6 bytes as defined by
padding_length field --> length 4 bytes

As you can see, the total length of this packet is 4 + 1 + 1 + 6 = 12
bytes.

But RFC4253 section 6 says: 
> Each packet is in the following format:
>
>       uint32    packet_length
>       byte      padding_length
>       byte[n1]  payload; n1 = packet_length - padding_length - 1
>       byte[n2]  random padding; n2 = padding_length
>       byte[m]   mac (Message Authentication Code - MAC); m = mac_length
>
>       packet_length
>          The length of the packet in bytes, not including 'mac' or
the
>          'packet_length' field itself.
>
>       padding_length
>          Length of 'random padding' (bytes).
>
>       payload
>          The useful contents of the packet.  If compression has been
>          negotiated, this field is compressed.  Initially, compression
>          MUST be "none".
>
>       random padding
>          Arbitrary-length padding, such that the total length of
>          (packet_length || padding_length || payload || random 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 is 255 bytes.
>
>       mac
>          Message Authentication Code.  If message authentication has
>          been negotiated, this field contains the MAC bytes.  Initially,
>          the MAC algorithm MUST be "none".
>
>    Note that the length of the concatenation of 'packet_length',
>    'padding_length', 'payload', and 'random
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 or receiving packets.  Also note that the
>    insertion of variable amounts of 'random padding' may help
thwart
>    traffic analysis.
>
>    The minimum size of a packet is 16 (or the cipher block size,
>    whichever is larger) bytes (plus 'mac').  Implementations SHOULD
>    decrypt the length after receiving the first 8 (or cipher block size,
>    whichever is larger) bytes of a packet.

So why OpenSSH is sending a packet with a length of 12 ?
Is there something I missed ? (particularly with AEAD ciphers ?)

I attached the picture of the decrypted captured frame.

Thanks for help

Kind regards,
Nicolas Baranger

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3839

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Yes, AEAD ciphers are different. E.g. see
https://datatracker.ietf.org/doc/html/rfc5647#section-7.2

chacha/poly is a little different, as the length field is handled quite
separately to the payload.
https://datatracker.ietf.org/doc/html/draft-ietf-sshm-chacha20-poly1305-00

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3839

--- Comment #2 from nicolas.baranger at 3xo.fr ---
Thanks for answer and provided links. 
It seems that aes***-gcm + chacha20-poly1305 are both violating
RFC4253: one has it length_prefix not encrypted and a minimal size of
20 with a payload of 1 and packet_length [mod16] = 4,  and the other
allow a total packet size of 12 while having (padding_length + payload
+ padding_string) [mod8] = 0 but (packet_length padding_length +
payload + padding_string) [mod8] = 4 

I'm trying to find a "general rule" for checking the minimum
packet
size but I'm not sure it's relevant (or possible) in every situations. 

Maybe I should simply check the cipher and hardcoded minimum
packet_length for each cipher.

What would you recommend ?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3839

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
They are not violating RFC4253 because they are different binary packet
protocol specifications that implement their own different rules. The
RFC4253 rules only apply to the original SSH ciphers and MACs.

I don't think there's a general rule that fits every situation.

Implementations that use *-etm at openssh.com MAC algorithms are another
transport case you need to consider. IIRC they are somewhere between
AES-GCM and chachapoly - they send the length in cleartext like AES-GCM
but apply the cipher blocksize only to the padlen+payload+padding.

So four possible cases:

1. *cbc/*ctr ciphers with original RFC4253 MACs (or umac*@openssh.com)
2. *cbc/*ctr ciphers with *-etm at openssh.com MACs (or umac*@openssh.com)
3. aes*-gcm at openssh.com
4. chacha20-poly1305 at openssh.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3839

--- Comment #4 from nicolas.baranger at 3xo.fr ---
Thanks for answer and explanations about RFC4253.
Ok I will have a look at *-etm at openss.com too and I will go ahead with
the 4 cases you point out.
Huge thanks again
Nicolas

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.