RFC Errata
Found 2 records.
Status: Held for Document Update (1)
RFC 8270, "Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits", December 2017
Source of RFC: curdle (sec)
Errata ID: 5501
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-09-21
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-09-23
Section 3 says:
[RFC4419] specifies a recommended minimum size of 1024 bits for k, which is the modulus length of the DH group. It also suggests that, in all cases, the size of the group needs be at least 1024 bits.
It should say:
[RFC4419] specifies a recommended minimum size of 1024 bits for k, which is the modulus length of the DH group. It also suggests that, in all cases, the size of the group needs to be at least 1024 bits.
Notes:
Fix a typo (missing "to").
Status: Rejected (1)
RFC 8270, "Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits", December 2017
Source of RFC: curdle (sec)
Errata ID: 5502
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-09-21
Rejected by: Deb Cooley
Date Rejected: 2024-10-30
Section 5 says:
A malicious client could cause a Denial of Service by intentionally making multiple connections that are less than 2048 bits in size. Therefore, operating systems SHOULD NOT log DH groups that are less than 2048 bits in size, as it would create an additional attack surface.
It should say:
A malicious client could cause a Denial of Service by intentionally making multiple connections that are less than 2048 bits in size. Therefore, operating systems without any rate-limited logging SHOULD NOT log DH groups that are less than 2048 bits in size, as it would create an additional attack surface.
Notes:
Instead of ignoring attacks, the administrator wants to know when one is taking place, particularly if it is an intense one which would lead to a denial of service, as suggested by the authors. Thus, using a rate-limited logging mechanism is an appropriate solution to keep records of the attack, and to notify the administrator in real-time then he can take actions if he wants to. As there might not be other ways to inform the administrator of an attack taking place, not logging at all is the last choice.
--VERIFIER NOTES--
We are rejecting because it is not clear what course of action an administrator has when seeing such log messages, so the usefulness of this kind of logging seems marginal at best and the security considerations advice to just silently drop these connections without logging them still seems best.