Subject: [TLS] FFDHE and SHOULDs on usage

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Nov 2014 12:05:02 -0800

The thesis here is that strong groups (and 2048 isn't that strong) are
extremely expensive to verify, and folks are unlikely to do that
verification.  Therefore, the pick-your-own-group method is not just a
bad idea, but an invitation to attack.

The draft as written, however, allows all sorts of escapes in the form
of SHOULD-based statements for clients and servers to negotiate FFDHE
ciphersuites with the server doing PYOG.

Clients who want to do PYOG can simply not support (or pretend to not
support) this draft.

## Details:

The draft says that, for servers:

   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 SHOULD NOT select an FFDHE ciphersuite.

I think that this needs to be a MUST.  If the client is willing to
take the servers choice of group, then it would not be including the
fixed groups.

Similarly, all the SHOULDs in the client behaviour section needs to be hardened.

OLD:
   The compatible client that wants to be able to negotiate strong FFDHE
   SHOULD send a "Supported Groups" extension
NEW:
   The compatible client that wants to be able to negotiate strong FFDHE
   sends a "Supported Groups" extension
Rationale:
   This is purely axiomatic.

OLD:
   A client that offers any of these values in the elliptic_curves
   extension SHOULD ALSO include at least one FFDHE ciphersuite in the
   Client Hello.
NEW:
   A client that offers a NamedCurve extension containing a FFDHE group
   cannot use
Rationale:
   No need for normative language here, this is purely a (relevant)
observation.  And "SHOULD ALSO" doesn't appear in RFC 2119 ;)

The only escape valve that is needed already exists:
      If none of the offered groups match, the server is not
      compatible with this draft.  The client MAY decide to continue the
      connection if the selected group is acceptable under local policy,
      or it MAY decide to terminate the connection with a fatal
      insufficient_security(71) alert.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 13 Nov 2014 21:19:24 +0100

Martin Thomson <[email-masked]>:

> observation.  And "SHOULD ALSO" doesn't appear in RFC 2119 ;)

All these suggestions look right to me.

If we really wanted to allow explicitly specified ("PYOG") FFDHE groups as
a fallback, we should create the equivalent of RFC 4492's
arbitrary_explicit_prime_curves NamedCurve. (We don't actually want that, I
hope.)

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Nov 2014 12:29:42 -0800

On 13 November 2014 12:19, Bodo Moeller <[email-masked]> wrote:
> If we really wanted to allow explicitly specified ("PYOG") FFDHE groups as a
> fallback, we should create the equivalent of RFC 4492's

I teased that idea in the meeting, but it's a bad idea ;)