Re: [TLS] FFDHE and SHOULDs on usage

[Daniel Kahn Gillmor <[e-mail]>]

Hi Martin--

Thanks for the review!

On Thu 2014-11-13 15:05:02 -0500, Martin Thomson wrote:
> 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.

agreed.

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

this also makes sense.

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

The above two edits make sense to me, and i propose to reflect them with
the following diff:


diff --git a/tls-negotiated-ff-dhe.xml b/tls-negotiated-ff-dhe.xml
index ef73355..3af4c30 100644
--- a/tls-negotiated-ff-dhe.xml
+++ b/tls-negotiated-ff-dhe.xml
@@ -242,7 +242,7 @@
       mechanism.</t>
 
       <t>The compatible client that wants to be able to negotiate
-      strong FFDHE SHOULD send a "Supported Groups" extension 
+      strong FFDHE sends a "Supported Groups" extension 
       (identified by type elliptic_curves(10) in <xref target="RFC4492"/>) in the
       ClientHello, and include a list of known FFDHE groups in the
       extension data, ordered from most preferred to least preferred.
@@ -295,13 +295,13 @@
       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.
+      server, then the server MUST NOT select an FFDHE ciphersuite.
       In this case, the server SHOULD select an acceptable non-FFDHE
       ciphersuite 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 ciphersuites are acceptable to the server, the server
-      SHOULD end the connection with a fatal TLS alert of type
+      MUST end the connection with a fatal TLS alert of type
       insufficient_security(71).
       </t>
       <t>

The "In this case, the server SHOULD select..." part remains a SHOULD
because of the possibility of the peer-incompatibility case outlined in
the last sentence.  I welcome concrete suggestions for other ways to
word this decision process if anyone has a clearer proposal.

> 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 edit as phrased explicitly above makes no sense.  At least the "OLD"
had a complete sentence ;)

I propose to address the identified normative language with the
following change:

diff --git a/tls-negotiated-ff-dhe.xml b/tls-negotiated-ff-dhe.xml
index 3af4c30..e9202a3 100644
--- a/tls-negotiated-ff-dhe.xml
+++ b/tls-negotiated-ff-dhe.xml
@@ -252,9 +252,9 @@
       ordering SHOULD be based on client preference, but see <xref
       target="preference_ordering"/> for more nuance.</t>
 
-      <t>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.</t>
+      <t>A client that offers a "Supported Groups" extension
+      containing an FFDHE group should also include at least one FFDHE
+      ciphersuite in the Client Hello.</t>
 
       <t>A client who offers a group MUST be able and willing to
       perform a DH key exchange using that group.</t>


WDYT?

        --dkg