Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt

From: Peter Gutmann <[email-masked]>
Date: Thu, 24 Jul 2014 14:53:46 +0000

<[email-masked]> writes:

>   Traditional finite-field-based Diffie-Hellman (DH) key exchange
>   during the TLS handshake suffers from a number of security,
>   interoperability, and efficiency shortcomings.  These shortcomings
>   arise from lack of clarity about which DH group parameters TLS
>   servers should offer and clients should accept.  This document offers
>   a solution to these shortcomings for compatible peers by establishing
>   a registry of DH parameters with known structure and a mechanism for
>   peers to indicate support for these groups.

Some comments:

- Why not just use the well-known and -accepted IKE groups from RFC 3526 for
this?  In fact why invent entirely new groups (that don't even cover the
existing range in RFC 3526) when there's already well-established ones
available?

- What's the thinking behind a 2432-bit group?  2048-bit I could understand,
2560 bits perhaps, but 2432?

- Publishing the values of q (rather than just telling people how to calculate
them) would be good, since it'd provide known-correct values for them.

In general though, we don't need yet another set of parameters, all that's
needed is a mechanism for specifying the existing RFC 3526 groups.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Jul 2014 14:00:51 -0400

> existing range in RFC 3526) when there's already well-established ones

That’s been asked at the meeting. No particular answer.

> 2560 bits perhaps, but 2432?

I asked that at the meeting. The answer is that this number supposedly exactly matches the 112-bit level of security. 

> needed is a mechanism for specifying the existing RFC 3526 groups.

And that’s assuming we even want FFC parameters (as opposed to ECC).

Yoav

---

From: Andrey Jivsov <[email-masked]>
Date: Thu, 24 Jul 2014 16:45:29 -0400

> That’s been asked at the meeting. No particular answer.

Pros:
* a resourceful attacker will not be able to look for collisions within 
a single database of (key, key*G). He needs two, for IKE and TLS.
* this adds one bit of security

Cons:
* It adds only one bit of security
* an implementation that shares code between IKE and TLS will need to 
store an additional hardcoded prime.

Most people will not have strong preferences here, I assume.

> I asked that at the meeting. The answer is that this number supposedly exactly matches the 112-bit level of security.
IMO this comes down to alignment with other standards and practice.

If 2048 RSA is being paired with dldhe2432, this would waste ~400 bits.

More generally, deviating from 2048, 3072, 4096, etc will result in a 
similar waste of resources and add to uncertainty on how to match security.

Second, the map between the bit security and modp size has been a 
dynamic quantity over the years. There bring another benefit to stick 
with a round number: longer shelf life of the document.

> And that’s assuming we even want FFC parameters (as opposed to ECC).
There is a benefit for TLS 1.2 and earlier versions. It should be at 
least MAY in 1.3 to assure smooth transition.

( Although this only matters for reused KE parts, we get an 
exceptionally cheap validation that that the peer's part belongs to a 
large subgroup, almost for free. )

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 25 Jul 2014 01:13:26 -0400

> existing range in RFC 3526) when there's already well-established ones

There's a possibility that a very expensive (e.g. precomputation) attack
exists that can be mounted against any given group.  If we reuse the
same group used by other mechanisms (e.g. ipsec) then the value for
mounting such an expensive attack goes up.

Selecting a different group forces an attacker to choose which group to
attack.

> 2560 bits perhaps, but 2432?

This was based on the 112-bit symmetric equivalence published by ECRYPT
II.  The ECRYPT document is referenced in the draft.

> them) would be good, since it'd provide known-correct values for them.

by q i think you mean (p-1)/2 -- i'm happy to document those values
explicitly in the draft if you think that would be useful.

Regards,

	--dkg

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 27 Jul 2014 00:11:47 +0300

> Selecting a different group forces an attacker to choose which group to

Both IKE and TLS are high value enough that (choose your favorite 
3-letter acronym) would gladly spend the money to break either or both, 
if such an attack was possible. And actually the logical outcome of your 
argument is that we need 10 or 100 new named groups in TLS to minimize 
this risk. I don't think anybody is seriously considering that.

Thanks,
	Yaron