Re: [TLS] RFC4492bis - Removing ECDH

[Michael Clark <[e-mail]>]

Hi,

After spending 14 years in Asia I get mixed up with holidays and started
calling them Solstice holidays and Lunar holidays (Feb 19th this year).
I'm hoping I can have a break in the Lunar New Year. My family in New
Zealand celebrated Solstice holidays without us... as we still trying to
/Escape from Singapore/ (reminds me of Snake Plissken)... we'll make it
out. We still have Internet access here. (*1,*2) ;-).

Yes. You might want more consensus, however as a data point, I am in
support of ephemeral key negotiation mechanisms that /in theory/
preserve forward secrecy and for removing those that leave
administrators hamstrung (and aren't implemented). i.e. fine with
removing ECDH. There appears to be an emerging consensus from server
administrators and the certificates issued from all major vendors have
"Parameters: None". In the case they were used in practice, they would
make attack mitigation depend on third parties.

My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically
unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH
requires the CA to embed static named or explicit points in
certificates. The practice is that implementations let server
administrators choose and /sign/ *somewhat* ephemeral parameters e.g.
secp256r1,  secp384r1 works widely, but secp521r1 failed in my tests
with Win8.1 IE11; this report matches my data point: (*3). I use the
word /sign/ loosely until we have a proof that handshake messages can't
be replaced in situ (*4). i.e. the client and server establish a chain
of trust from their first Hellos to the pre-master secret establishment;
which is possible with careful refinements to the protocol (constant
salt in AD across all handshake messages). This of course then pushes an
integrity problem down to another layer. i.e. DNSSEC (*5).

It raises another question. Is DH_anon a misnomer? Should it be
DHE_anon? Is it used anywhere in practice?

Michael.

[1] http://foreignpolicy.com/2014/07/29/the-social-laboratory/
[2] https://tools.ietf.org/html/rfc7258
[3] https://twitter.com/ericlaw/status/532296076670533632
[4]
http://arstechnica.com/security/2015/01/gogo-issues-fake-https-certificate-to-users-visiting-youtube/
[5] http://www.internetsociety.org/deploy360/dnssec/maps/


On 7/1/15 10:23 pm, Yoav Nir wrote:
> Hi.
>
> I realize this was sent right in the middle of the holiday season, so
> I’ll give it another try.
>
> Please have a look at the pull request and post comments to the list
> about whether you’re fine with removing ECDH.
>
> Thanks
>
> Yoav
>
>> On Dec 16, 2014, at 12:29 AM, Yoav Nir <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> Hi.
>>
>> I’ve created pulll request #2 for removing references to ECDH (static
>> elliptic curve key) key exchange and ciphersuites.
>>
>> https://github.com/tlswg/rfc4492bis/pull/2
>>
>> Nikos suggested it
>> here: http://www.ietf.org/mail-archive/web/tls/current/msg14555.html
>> Yes, there are other suggestions there, but I’d like to take them one
>> by one.
>>
>> Let me know what you think
>>
>> Yoav
>>