Errata

Status:

Verified

Type:

Technical

Reported By:

denis bider

Date Reported:

2015-11-13

Verified by:

Paul Wouters

Date Verified:

2023-07-28

Section 7.1 says:

[[ A paragraph is missing in this section to clarify implementation
   requirements for the reserved field. This paragraph could suitably
   be inserted after the description of first_kex_packet_follows. ]]

It should say:

      (reserved field)
         Servers and clients may or may not be aware of a future
         extension to this RFC that specifies a use for this field.

         Servers and clients that are NOT aware of such an extension:
         - MUST send this field with value zero;
         - MUST NOT act on any value of this field when received,
           whether the received value is zero or non-zero;
         - in key exchange, MUST properly hash the actual received
           value of this field.

         This behavior is REQUIRED to allow use of this field in
         future protocol extension.

Notes:

RFC 4253 defines the KEXINIT reserved field as follows:

uint32       0 (reserved for future extension)

This has in practice not been sufficient for developers to understand the requirements for sending and handling this field.

At least one common implementation will currently fail key exchange if the field is non-zero, because it forgets to decode it, and just assumes it is always zero.

At least one other implementation will currently disconnect if the field is non-zero, because it takes the above definition to mean that the field must be zero when received.

The above paragraph clarifies the correct treatment of this field. This has been discussed during November 2015 with other implementers on the "ietf-ssh@netbsd.org" mailing list. There appears to be consensus that the above is the correct treatment.

Status:

Verified

Type:

Editorial

Reported By:

Pasi Eronen

Date Reported:

2008-08-08

Verified by:

Pasi Eronen

Date Verified:

2008-08-11

Section 12 says:

         SSH_MSG_DISCONNECT             1
         SSH_MSG_IGNORE                 2
         SSH_MSG_UNIMPLEMENTED          3
         SSH_MSG_DEBUG                  4
         SSH_MSG_SERVICE_REQUEST        5
         SSH_MSG_SERVICE_ACCEPT         6
         SSH_MSG_KEXINIT                20
         SSH_MSG_NEWKEYS                21

It should say:

         SSH_MSG_DISCONNECT             1
         SSH_MSG_IGNORE                 2
         SSH_MSG_UNIMPLEMENTED          3
         SSH_MSG_DEBUG                  4
         SSH_MSG_SERVICE_REQUEST        5
         SSH_MSG_SERVICE_ACCEPT         6
         SSH_MSG_KEXINIT                20
         SSH_MSG_NEWKEYS                21
         SSH_MSG_KEXDH_INIT             30
         SSH_MSG_KEXDH_REPLY            31

Notes:

This errata combines the partial errata reported by Denis Bider (errata ID 152 on 2006-01-23) and Dwayne Litzenberger (errata ID 1408 on 2008-04-11).

Status:

Verified

Type:

Editorial

Reported By:

Oleg Andriyanov

Date Reported:

2016-06-27

Verified by:

Paul Wouters

Date Verified:

2023-07-28

Section 5.3 says:

   o  The minimum size of a TCP/IP header is 32 bytes.  Thus, the
      increase is actually from 33 to 51 bytes (roughly).

   o  The minimum size of the data field of an Ethernet packet is 46
      bytes [RFC0894].  Thus, the increase is no more than 5 bytes.
      When Ethernet headers are considered, the increase is less than 10
      percent.

It should say:

   o  The minimum size of a TCP/IP header is 32 bytes.  Thus, the
      increase is actually from 33 to 60 bytes (roughly).

   o  The minimum size of the data field of an Ethernet packet is 46
      bytes [RFC0894].  Thus, the increase is no more than 14 bytes.
      When Ethernet headers are considered, the increase is less than 25
      percent.

Notes:

As the minimum size of SSH message is 28, the minimum size of the TCP segment containing SSH message must be 32 + 28 == 60 bytes (as opposed to 32 + 1 in case of transmission of plain text over TCP).

Status:

Rejected

Type:

Editorial

Reported By:

denis bider

Date Reported:

2006-01-23

Rejected by:

Pasi Eronen

Date Rejected:

2008-08-11

Section 12 says:

    SSH_MSG_DISCONNECT             1
    SSH_MSG_IGNORE                 2
    SSH_MSG_UNIMPLEMENTED          3
    SSH_MSG_DEBUG                  4
    SSH_MSG_SERVICE_REQUEST        5
    SSH_MSG_SERVICE_ACCEPT         6
    SSH_MSG_KEXINIT                20
    SSH_MSG_NEWKEYS                21

It should say:

    SSH_MSG_DISCONNECT             1
    SSH_MSG_IGNORE                 2
    SSH_MSG_UNIMPLEMENTED          3
    SSH_MSG_DEBUG                  4
    SSH_MSG_SERVICE_REQUEST        5
    SSH_MSG_SERVICE_ACCEPT         6
    SSH_MSG_KEXINIT                20
    SSH_MSG_NEWKEYS                21
    SSH_MSG_KEXDH_INIT             30
    SSH_MSG_KEXDH_REPLY            3

Notes:

 --VERIFIER NOTES-- 
Errata IDs 152 and 1408 are combined to 1486.

Status:

Rejected

Type:

Editorial

Reported By:

Dwayne Litzenberger

Date Reported:

2008-04-11

Rejected by:

Pasi Eronen

Date Rejected:

2008-08-11

Section 12 says:

    SSH_MSG_KEXDH_INIT             30
    SSH_MSG_KEXDH_REPLY            3

It should say:

    SSH_MSG_KEXDH_INIT             30
    SSH_MSG_KEXDH_REPLY            31

Notes:

This is a transcription error in the erratum dated 2006-01-23.  Section 12 says "numbers 30-49 are used for kex packets", so using 3 for SSH_MSG_KEXDH_REPLY is clearly wrong.  OpenSSH and python-paramiko both use 31, not 3.
 --VERIFIER NOTES-- 
Errata IDs 152 and 1408 are combined into 1486.