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

[Andrey Jivsov <[e-mail]>]

On 7/24/2014 2:00 PM, Yoav Nir wrote:
> On Jul 24, 2014, at 10:53 AM, Peter Gutmann <[e-mail]> wrote:
>
>> <[e-mail]> 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?
> 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.

>> - What's the thinking behind a 2432-bit group?  2048-bit I could understand,
>> 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.
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.

>> - 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.
> 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. )