I am in favor of this erratum, or rather of correcting it On Sun, Jan 15, 2017 at 5:07 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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 > > <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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
