RFC Errata
Found 5 records.
Status: Verified (3)
RFC 4253, "The Secure Shell (SSH) Transport Layer Protocol", January 2006
Note: This RFC has been updated by RFC 6668, RFC 8268, RFC 8308, RFC 8332, RFC 8709, RFC 8758, RFC 9142
Source of RFC: secsh (sec)
Errata ID: 4533
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: denis bider
Date Reported: 2015-11-13
Verifier Name: 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.
Errata ID: 1486
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2008-08-08
Verifier Name: 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).
Errata ID: 4721
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Oleg Andriyanov
Date Reported: 2016-06-27
Verifier Name: 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 (2)
RFC 4253, "The Secure Shell (SSH) Transport Layer Protocol", January 2006
Note: This RFC has been updated by RFC 6668, RFC 8268, RFC 8308, RFC 8332, RFC 8709, RFC 8758, RFC 9142
Source of RFC: secsh (sec)
Errata ID: 152
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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.
Errata ID: 1408
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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.