Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 10:42:07 +0100

Hiya,

On 01/04/15 05:27, Martin Rex wrote:
> Martin Thomson wrote:
>> Stephen Farrell <[email-masked]> wrote:
>>>
>>> #1 Have we tested in the wild that using elliptic_curves (10)
>>> in the ClientHello won't trigger some ECC code that causes
>>> handshakes to barf?
>>
>> Firefox sends the supported_curves extension in every handshake and so
>> do most browsers.  So for those, the risk of intolerance is obviously
>> quite low.  That's not hard numbers obviously, but that's a lot of
>> ClientHello messages with the extension.

Good stuff. But see below.

> 
> I think Stephen might have meant something else.
> 
> RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.):
> 
>    https://tools.ietf.org/html/rfc4492#section-4
> 
> 
>    The client MUST NOT include these extensions in the ClientHello
>    message if it does not propose any ECC cipher suites. 

Ooh - good catch, I hadn't spotted that. This draft is updating 4492
though so we can validly change that, but if we're doing so (and I
guess we are) then it'd be better to be very explicit about it, e.g.
by adding a sentence saying that we're changing that specific MUST NOT.

> and the above requirement seems to prohibit a non-ECC client from
> using the named FFDHE parameters through the ECC named curve extension
> _without_ accompanying ECC cipher suites.

Right. That's the kind of thing I was wondering about.

I'll happily accept the wg's word on this, but to what extent have
we checked that we're not breaking something with this change in
semantics. (It's a small, but real, change.)

Thanks,
S.

> -Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 2 Apr 2015 04:05:17 +0200 (CEST)

Stephen Farrell wrote:
>Martin Rex wrote:

I believe that this is *NOT* an option here (more below).

> semantics. (It's a small, but real, change.)

The problem with the quoted requirement in rfc4492 is (similar to several
highly bogus and/or overbroad requirements in other TLS-related RFCs),
that it does not distinguish PDU content from communication peer behaviour,
and does not declare whether that requirement applies only to sender
or also to recipient.

The result is, that there may easily exist server implementation of rfc4492
which abort the TLS handshake when they receive a TLS ClientHello with
the TLS ECC named_curve extension (and only ffdhe named curves in it)
but no accompanying ECC cipher suites in the ClientHello cipher_suites_list,
and that interoperability failure OUGHT to be avoided.  REALLY.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 11:38:39 +0100

> and that interoperability failure OUGHT to be avoided.  REALLY.

Right, it is a possible interop break. It seems the browser folks
are confident it won't bite them (did they test yet without any ECC
ciphersuites?) but that (so far) we've not heard from others. I'd like
to hear more myself, but this is something the WG could choose to do
and, if done carefully, that can be fine. OTOH, it could also be a
mistake, if not done sufficiently carefully, which is why I'm asking
about it. (Right now, I think I need more input still, but it could
also be that that's already in the list archive, I'm not sure.)

Cheers,
S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 03 Apr 2015 16:22:34 -0400

Hi all--

Thanks to Stephen and both Martins for the review.

> by adding a sentence saying that we're changing that specific MUST NOT.

I'd be happy to add a sentence to the draft clarifying this point.  If
anyone wants to propose concrete text i'm happy to use it, or i'll try
to come up with something short and sweet.

> semantics. (It's a small, but real, change.)

In practice, i've yet to find a TLS server that chokes when offered
these extensions without any ECC cipher suites.

GnuTLS as a client does not follow this MUST.  You can try it yourself
to connect to any server with something from the 3.x line:

 gnutls-cli --priority NORMAL:-ECDHE-RSA:-ECDHE-ECDSA $SERVER

looking with wireshark, you'll see that there are no ECC ciphersuites,
but the groups and point formats extensions are sent anyway.

I haven't done a full zmap scan of the full ipv4 space, but i've tested
many systems and have not found any servers that abort just because
these extensions are present without an ECC ciphersuite.

      --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 03 Apr 2015 16:25:40 -0400

> and does not declare whether that requirement applies only to sender

This suggestion seems to imply that we should be relaxing this
requirement (we've relaxed other overeager requirements in TLS that just
cause interop failure), which, iiuc, is what Stephen was proposing also.

> and that interoperability failure OUGHT to be avoided.  REALLY.

If you know of any server implementations that do this, please point me
(and/or the list) to them.

    --dkg

---

From: Geoffrey Keating <[email-masked]>
Date: 03 Apr 2015 13:46:25 -0700

> and that interoperability failure OUGHT to be avoided.  REALLY.

There's no way an implementation can be sure there are no ECC cipher
suites proposed unless it recognizes every proposed cipher suite, and
I understand that elsewhere we're proposing a complete redesign of the
cipher suites so there will always be cipher suites that a pre-1.3
implementation does not recognize.

Implementations could be buggy, of course---but that's always true.