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

[Tony Arcieri <[e-mail]>]

On Wed, Jun 3, 2015 at 1:22 AM, Tony Arcieri <[e-mail]> wrote:

> On Wed, Jun 3, 2015 at 1:07 AM, Peter Gutmann <[e-mail]>
> wrote:
>
>>
>> *You've got that exactly reversed, it's not "DHE is breaking Java
>> handshakes", it's "(Sun/Oracle's) Java is breaking DHE handshakes".*
>>
>
> Here in the real world things are written in Java and we have to deal with
> that. Idealistically I'd wave a magic wand and all of the legacy cruft
> would go away. Unfortunately I don't have that magic wand. I have to keep
> the real-world systems talking to each other.
>
> I want real-world solutions to real-world problems, not idealistic
> zealotry.
>

Worse, I didn't bring up Java. Java was specifically cited in argument of
this draft:

On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario <[e-mail]> wrote:

> as it was pointed out many times
>

^^^ perhaps this was the line that set me off, but this is painfully
antagonistic to me especially given what I've been dealing with recently.
Saying things like this is tantamount to a personal attack and if you have
a technical argument to make this is possibly the worst way you can prefix
it. Dear Hubert, don't frame your argument this way, it just makes me
dislike you.

adding support for ECC is complex (both because of compexity of ECC and
> because it's
>
a completely new set of algorithms)
>

Many JCE providers already support ECC including BouncyCastle and the
default JCE providers in Java 7 and 8 so this statement is just wrong.
Modern Java implementations just won't negotiate DHE unless the server
can't speak ECDHE.


> This allows us to move away from defaulting to 1024bit or 2048bit on server
> side in fear of breaking, for example, Java based clients


Please show me an HTTPS server I can point my DHE-enabled Java 6 and 7
clients at and have them successfully negotiate a TLS session. I dare you.

-- 
Tony Arcieri