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

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 00:56:05 +0100

Hiya,

I've done my AD review of this, and it's very good. I have
two questions I'd like to check on before starting IETF
last call. If the answers are already in the list archive,
then just pointing there is entirely fine. If not, well,
they're not such hard questions:-)

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

#2 I've never quite gotten the reasoning behind not giving
any names to any of the RFC3526 curves and I think that
question deserves an answer (to be in the list archive).
So - why not?

Cheers,
S.

PS: I also have a bunch of nitty nits, feel free to handle
those however is best.

- intro: What is "Traditional TLS"? Ye olde something or
other? :-)

- intro: "p > 1024 bits" is fine by me but better would be
to say "p is longer than 1024 bits"

- s3, 2nd para: I suggest a para break before you get to the
bit about both ECC and DHE.

- s3, 3rd para: what is the "these" in here? This reads a
bit oddly.

- 5.1: "public key" is less common than "public value" I
think, when talking about DH. FWIW, I prefer value as saying
key confuses some people into thinking this is a long term
value.

- 5.2: 4419 has a reference to a Paul Van Oorschot paper
that justifies the security here. Did we check there are no
more recent results? (Esp ones that might invalidate the
optimisation.) Could also be good to include whatever is
today's best reference for this directly rather than just
via 4419.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2015 17:29:41 -0700

> in the ClientHello won't trigger some ECC code that causes

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.

---

From: [email-masked] (Martin Rex)
Date: Wed, 1 Apr 2015 06:27:31 +0200 (CEST)

Martin Thomson wrote:
> Stephen Farrell <[email-masked]> wrote:
>>

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. 

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.

-Martin