Subject: Re: [TLS] FFDHE and SHOULDs on usage

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 15 Apr 2015 14:22:05 -0400

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Apr 2015 12:05:26 -0700

> +      ciphersuite in the Client Hello.</t>

I apologize for not completing the

It's been a while, so I went back and re-read this little bit,
prompted largely by your choice to move to a lowercase should:

   The compatible client that wants to be able to negotiate strong FFDHE
   SHOULD send a "Supported Groups" extension (identified by type
   elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a
   list of known FFDHE groups in the extension data, ordered from most
   preferred to least preferred.  If the client also supports and wants
   to offer ECDHE key exchange, it MUST use a single "Supported Groups"
   extension to include all supported groups (both ECDHE and FFDHE
   groups).  The ordering SHOULD be based on client preference, but see
   Section 6.1 for more nuance.

This is a little over-2119-y for me.  How about:

"""
A client that wants to negotiatiate strong FFDHE sends a ClientHello
containing a cipher suite that uses DHE key exchange and a "Supported
Groups" extension (identified by ...).  The "Supported Groups"
extension contains the FFDHE groups the client will accept.  If the
client also intends to accept ECDHE key exchange, the same "Supported
Groups" extension is used for both FFDHE and ECDHE groups.

Groups are ordered based on client preference, noting the additional
ordering considerations in Section 6.1.
"""

---

From: Sean Turner <[email-masked]>
Date: Thu, 16 Apr 2015 10:59:03 -0400

Top posting here to make sure folks not that Martin’s de-2119ing some of the text, but to me at least it looks like it expresses the same requirements.  Please let us know whether you disagree with this change by the 2015-04-25.

spt

On Apr 15, 2015, at 15:05, Martin Thomson <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 16 Apr 2015 10:44:08 -0400

> I apologize for not completing the

:)

> ordering considerations in Section 6.1.

I'm willing to drop the 2119 language in this section if other people
think that it is inappropriate.  Some of it seems relevant for interop
to me (e.g. 'MUST use a single "Supported Groups" extension' just echoes
5246's restriction 'There MUST NOT be more than one extension of the
same type.')

What do others think here?

Also, this rewrite says "ordered based on client preferences" but
doesn't indicate which order based on client preferences: most preferred
to least preferred or the other way around.  It may be pedantic, but
this is exactly the sort of pedantry that RFCs should include.

     --dkg

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Apr 2015 13:59:43 -0700

> this is exactly the sort of pedantry that RFCs should include.

I was merely being (over-)economical.  By all means, add the qualification.

---

From: [email-masked] (Martin Rex)
Date: Sat, 18 Apr 2015 05:10:52 +0200 (CEST)

> this is exactly the sort of pedantry that RFCs should include.

Could we just scrap the "based on xxx preference" nonsense entirely?

The sender of the list sends whatever it sees fit, and the receiver
of the list has the privilege to pick what ever the receiver believes
is most appropriate from the receivers point of view.

I never understood why (a) such a silly suggestion was made for
the ordering of cipher suites in ClientHello and (b) why any TLS server
implementaion would care for the client's ordering rather than enforcing
the server preference.  If the client does not want something, it must
not offer it.  If the server does not want something, it must not pick it.

-Martin

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 17 Apr 2015 23:31:00 -0700

On 04/17/2015 08:10 PM, Martin Rex wrote:
...
> not offer it.  If the server does not want something, it must not pick it.

On ClientHello:

Presumably the existence of ordering of client preferences in the TLS 
spec provides a way for a client to tell that "I really prefer this 
ciphersuite, while I have these others mostly for interoperability". 
There are other benefits.

A server should be able to follow its ordering. One issue with making 
the server rule is that current TLS negotiation mechanism makes a) what 
server supports invisible, b) the ordering of the server set invisible, 
so at least from visibility/troubleshooting/tie-breaking point of view 
there is a benefit to consider the client order.

( It's not too difficult to write a tool that discovers a) and b), but I 
am only aware of tools that report a). ).

One model that can work for a server is to split all supported 
ciphersuites into categories, order by these server categories and by 
ClientHello order within a category. For a simple example consider 
secure and legacy categories. The server prefers any ciphersuite from 
secure category to any from legacy. In more realistic scenarios there 
are more categories and the ordering of categories can be controlled by 
a policy. After the server selects the top category that it prefers, 
inside each category the server selects ciphers according to the client 
order.

This thread is about groups. Here, as Martin said, if the client offers, 
say only ECDHE groups, the client order may not be relevant.

The ordering of the mix of ECDHE+DHE groups can be useful in theory, but 
I expect that most clients will put ECDHE before DHE and servers that 
care about performance order by strength and type, by policy or 
hardcoding these preferences, leaving no say to the client.

---

From: Thijs van Dijk <[email-masked]>
Date: Sat, 18 Apr 2015 08:31:49 +0200

> not offer it.  If the server does not want something, it must not pick it.

I still think it's a reasonable safeguard against lazy server
implementations (e.g. mine): The naive way of implementing cipher agreement
is to loop through the client's suggestions and pick the first one both
client and server suport. If that happens to be an EXPORT/RC4 combo you're
out of luck.

However if either the client or the server exhibits a preference, you're
almost guaranteed to do better than both sides' worst case.

Furthermore, I think that conceptually, dropping client preference would
equate to making server preference a requirement. The TLS1.3 spec should
reflect this in some way, so it's not very language-economic either.

-Thijs

---

From: Hubert Kario <[email-masked]>
Date: Mon, 20 Apr 2015 14:41:45 +0200

> not offer it.  If the server does not want something, it must not pick it.

If you have a relatively recent desktop CPU you don't care if you're using AES 
or ChaCha20. But if you're on a CPU which doesn't have a hardware acceleration 
for AES and is relatively slow (think mobile ARM), then you really would 
prefer ChaCha20 cipher over AES.

So server should _consider_ client preference. And the clients should have an 
order which is sane.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic