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

From: Sean Turner <[email-masked]>
Date: Fri, 3 Apr 2015 10:22:54 -0400

On Mar 31, 2015, at 19:56, Stephen Farrell <[email-masked]> wrote:

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

Maybe I’m not following but are you asking that we retroactively name the "4096-bit MODP Group”?

spt

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 18:54:37 +0100

On 03/04/15 15:22, Sean Turner wrote:
>> #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?
> 

Right, that and any others we still like. The thought is that
we might get a minor security benefit if the client says that
they're ok with e.g. the 2048-bit MODP group thereby causing
some server to not try use a custom group or the old smaller
groups. (I mean that'd be a minor benefit compared to the
current situation, not compared to what the draft proposes.)

It's not a major thing as the client can still just check for
the RFC3626 groups but I'm not sure how likely it is that'd
be done. OTOH, anyone who updates their code to handle this
can just as easily adopt the new groups, and I don't think
there's any particular benefit to sticking with the RFC3526
groups (e.g. there's no dedicated h/w for those I think).

So if the answer is "yeah, we considered that and didn't like
it because <foo>" that's fine, I just don't recall having seen
it on the list.

It's also fine if the answer is "we didn't think of that, but
we still don't like it" btw:-)

S.

---

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

> it because <foo>" that's fine, I just don't recall having seen

There are two concrete (and related) answers in the draft as to why
we're not importing several pre-existing named groups:

 https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08#section-9.5
 https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08#section-10.1

Please let me know if there are any changes that could be made to make
the situation more clear, or if you disagree with the rationales.

    --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 21:48:26 +0100

> the situation more clear, or if you disagree with the rationales.

It's not that I disagree with 'em, but I don't find them
that compelling tbh. The best (to me) seems to be that
additional usage in multiple protocols makes for a more
attractive target. But the MODP groups are already used
in TLS, and naming them in this way might reduce the
liklihood that some implementation accepts groups without
checking 'em. (E.g. an updated client would have the code
to check that a known-named group has been selected by
the server, so might benefit even if the server hasn't
been updated).

However, let's proceed and please treat the above as just
another last call comment. In this case, you've responded
already so if nobody else wants to pursue the discussion
then we'll be all set.

S.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 21:49:20 +0100

Hi all,

So I've gotten responses for both issues, and will now start
the IETF LC. Please comment as part of that if you think there's
something more to be done.

Cheers,
S.

On 01/04/15 00:56, Stephen Farrell wrote:
> 
> 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?
> 
> Cheers,
> 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: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 03 Apr 2015 17:16:37 -0400

On Fri 2015-04-03 16:48:26 -0400, Stephen Farrell wrote:
> checking 'em.

The MODP groups are not explicitly used anywhere in the TLS specs
(though of course nothing prevents a TLS server from chooing to use one
of them).  Some of the MODP groups (with different generators in some
cases) are used in TLS SRP (this is not the standard FFDHE handshake),
but aiui, we're talking about killing off SRP anyway.

> (E.g. an updated client would have the code to check that a
> known-named group has been selected by the server, so might benefit
> even if the server hasn't been updated).

If it were already common practice to use strong MODP groups for FFDHE,
this might be a convincing argument.  But in the surveys i've seen, most
DHE implementations restrict themselves to 1024-bit FFDHE anyway,
possibly due to client incompatibility or lack of understanding of the
protocol.  Whether that's MODP 1024 or some other 1024-bit DHE group,
this is still too weak for most guarantees i'd like to see TLS be able
to make.

> already so if nobody else wants to pursue the discussion

sounds good to me.  thanks for the review and the feedback, Stephen.

       --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 22:19:42 +0100

On 03/04/15 22:16, Daniel Kahn Gillmor wrote:
>  Whether that's MODP 1024 or some other 1024-bit DHE group,

I fully agree that naming MODP1024 as part of this would be
a bad idea.

S.