RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Reported (1)

RFC 7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", August 2016

Source of RFC: tls (sec)

Errata ID: 4908

Status: Reported
Type: Technical

Reported By: Martin Thomson
Date Reported: 2017-01-16

Section 4 says:

   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).

It should say:

   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.

Report New Errata