RFC Errata
Found 2 records.
Status: Verified (1)
RFC 7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", August 2016
Source of RFC: tls (sec)
Errata ID: 7579
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Geiser
Date Reported: 2023-07-31
Verifier Name: Paul Wouters
Date Verified: 2024-03-21
Section Appendix A says:
The primes in these finite field groups are all safe primes; that is, a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is the base of the natural logarithm and square brackets denote the floor operation, the groups that initially populate this registry are derived for a given bit length b by finding the lowest positive integer X that creates a safe prime p where: p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1
It should say:
The primes in these finite field groups are all safe primes; that is, a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is the base of the natural logarithm and square brackets denote the floor operation, the groups that initially populate this registry are derived for a given bit length b by finding the lowest positive integer X that creates a safe prime p where: p = 2^b - 2^{b-64} + {[2^{b-130} * e] + X } * 2^64 - 1
Notes:
The multiplication sign ('*' in ASCII) is missing in the explanatory introduction of Appendix A that describes the equation used for deriving the primes. It is correct in all five concrete derivations A.1 through A.5
Status: Held for Document Update (1)
RFC 7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", August 2016
Source of RFC: tls (sec)
Errata ID: 4908
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2017-01-16
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17
Section 4 says:
If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list. If the extension is present with FFDHE groups, none of the client's offered groups are acceptable by the server, and none of the client's proposed non-FFDHE cipher suites are acceptable to the server, the server MUST end the connection with a fatal TLS alert of type insufficient_security(71).
It should say:
If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list.
Notes:
The text is overly prescriptive about the alert code that needs to used if there are no acceptable cipher suites available. If the server is unable to pick a cipher suite, it can send a handshake_failure(40) alert, which this text would prohibit. handshake_failure is at least equally valid in practice.
This eliminates the prescriptive text about the alert type.
Servers eliminate cipher suites from considerations in numerous ways. Being able to definitively identify the reason as a (perceived) shortcoming in the strength of the offered security is actually quite challenging in practice.
It's true that insufficient_security is perhaps a more desirable code to use in this case, but it's not generically possible to determine that the server configuration is "more secure" than the combinations on offer by the client. Consider also the possibility that it's the server that is insecure because it doesn't some of the options offered by the client. That's a general criticism of the value of insufficient_security, but it should at least motivate why insufficient_security should never be mandated in this way.
Paul Wouters(AD): After discussion with Martin, we propose that the correction required is only the removal of "of type insufficient_security(71).".
As Martin explains:
Having a MUST on this is not appropriate in that sense. What would be acceptable is:
[...] the server terminates the connection according to Section 4.1.1 of [RFC8446].
Of course, that would depend on time travel in the sense that RFC 7919 pre-dates TLS 1.3 by a fair bit and so it can't really refer to it like that.