The following errata report has been submitted for RFC7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)".
-------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7919&eid=4908 -------------------------------------- Type: Technical Reported by: Martin Thomson <martin.thom...@gmail.com> 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. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- 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
