For those interested in the guts, this came up when discussing https://bugzilla.mozilla.org/show_bug.cgi?id=1330618 where Hubert noted that NSS is not compliant with this requirement.
On 16 January 2017 at 13:51, RFC Errata System <rfc-edi...@rfc-editor.org> wrote: > 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
