[TLS] FFDHE and SHOULDs on usage

[Martin Thomson <[e-mail]>]

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.