Subject: [TLS] [Technical Errata Reported] RFC7919 (4908)

From: RFC Errata System <[email-masked]>
Date: Sun, 15 Jan 2017 16:51:40 -0800 (PST)

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-masked]>

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jan 2017 14:00:54 +1300

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.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jan 2017 01:07:28 +0000

On instruction from the WG chairs, or by acclamation, I will
approve this erratum. Silence OTOH means inaction:-)

S

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jan 2017 18:05:40 -0800

I am in favor of this erratum, or rather of correcting it

On Sun, Jan 15, 2017 at 5:07 PM, Stephen Farrell <[email-masked]>
wrote:

> >> 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.
> >>
> >> 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:
> >> -------------
> >> Title               : Negotiated Finite Field Diffie-Hellman Ephemeral
> Parameters for Transport Layer Security (TLS)
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 16 Jan 2017 10:59:08 +0100

> Original Text

I understand there will be servers which cannot follow the alert
recommendations on an RFC, but in that case why not replace the alert
types recommendation with a RECOMMENDED or SHOULD? It is good practice
for an RFC to specify the alerts to be send rather than leaving it up
to the implementer to figure out.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2017 05:33:24 -0800

> to the implementer to figure out.

IMO the spec should avoid prescribing alerts that require a certain
structure for
the negotiation code, which is what's happening here. In addition, we should
probably avoid RFC 2119-level requirements which we know that many
implementations will violate, even when they are SHOULD, not MUST

-Ekr