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

[Peter Bowen <[e-mail]>]

On Wed, Jun 3, 2015 at 1:48 AM, Tony Arcieri <[e-mail]> wrote:
> On Wed, Jun 3, 2015 at 1:43 AM, Peter Gutmann <[e-mail]>
> wrote:
>>
>> You seem to want everyone to change their behaviour in order to
>> accommodate
>> the fact that you've chosen to use a broken, buggy implementation
>
>
> These aren't clients under my control. I am talking about an entire language
> ecosystem here, not just my little corner of the world. But even if they
> were my clients, they wouldn't negotiate DHE anyway, because most
> configurations would prefer ECDHE.
>
> The "accommodation" you're defending is using finite-field Diffie-Hellman.
> Most clients support ECDH(E) and don't need to support finite-field
> Diffie-Hellman.
>
> I didn't even bring up Java, but it was cited as a reason for FFDHE to
> exist. However Java 7 and 8 clients would prefer ECDHE anyway. As they
> should, it's faster and uses smaller keys.
>
> This is a case of some legacy gunk left over from the early days of TLS
> breaking key exchange for clients that support better algorithms.

There are three classes of clients today:
1) Clients that support ECDH key exchange (with at least the NIST
P-256 and NIST P-384 curves)
2) Clients that do not support ECDH but support FFDH with larger modp sizes
3) Clients that do not support ECDH but support FFDH only with smaller
modp sizes (e.g. max size is only 1024 bits or 2048 bits)

This draft supposes that there will continue to be clients that fall
into the second class for the foreseeable future and given them a way
to declare that they are not in the third class.  While we would all
like to see every client in the first class, I don't think that is a
real option for a few more years.  Until then, we should allow clients
to indicate that they will accept reasonable modp sizes.  That was a
server can choose to allow them to use FFDH for key exchange but not
offer FFDH for other clients.

Thanks,
Peter