The following errata report has been held for document update for RFC7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid4908 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Martin Thomson <martin.thom...@gmail.com> Date Reported: 2017-01-16 Held by: Paul Wouters (IESG) Section: 4 Original Text ------------- 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). Corrected Text -------------- 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. -------------------------------------- RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10) -------------------------------------- Title : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Publication Date : August 2016 Author(s) : D. Gillmor Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
