Re: [TLS] RFC4492bis - Removing ECDH

[Yoav Nir <[e-mail]>]

Hi, Michael

> On Jan 8, 2015, at 4:21 AM, Michael Clark <[e-mail]> wrote:
> 
> 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).

#4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes?

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

It is a misnomer. It is not used on the web, but it is used in some situations. For example, my company’s firewalls use it to establish the initial trust between a firewall and the management station. They will establish a TLS connection with DH_anon (should be DHE_anon, I guess), and then run certificate enrollment over that.

Yoav