On instruction from the WG chairs, or by acclamation, I will approve this erratum. Silence OTOH means inaction:-)
S On 16/01/17 01:00, Martin Thomson wrote: > 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 > <[email protected]> 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 <[email protected]> >> >> 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
