Subject: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Mar 2014 17:04:01 -0700

(Renaming the thread, since this is what we seem to be talking about)

On 27 March 2014 16:55, Marsh Ray <[email-masked]> wrote:
> From: TLS [mailto:[email-masked]] On Behalf Of Alyssa Rowan
>>
>> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead?
>
> The general consensus at Microsoft is that we like ECDHE much better than the classic DHE.

I think that this is the general trend, but is it so bad that you
would want to prohibit DHE?

---

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Mar 2014 20:09:04 -0400

> would want to prohibit DHE?

Well, the DHE handshake has validation issues: implementations aren't
checking they get sensible inputs.
Fix that, and maybe you have an argument for keeping it. But as it
stands now the insecure resumption attacks are exploiting behavior in
DHE that isn't fixable without a DOS vector being introduced.

Sincerely,
Watson Ladd
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 28 Mar 2014 00:17:27 +0000

From: Martin Thomson [mailto:[email-masked]] 
> I think that this is the general trend, but is it so bad that you would want to prohibit DHE?

Historically we have opted to provide ECDHE *in place of* classic DHE.

- Marsh

http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651(v=vs.85).aspx
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Schannel Cipher Suites in Windows Vista

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5

The following cipher suites are supported by Schannel; however, they are not present by default. They must be added as necessary. For information about how to add cipher suites to the Schannel provider, see Prioritizing Schannel Cipher Suites.
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_CK_RC4_128_EXPORT40_MD5
SSL_CK_DES_64_CBC_WITH_MD5
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

---

From: Henrick Hellström <[email-masked]>
Date: Fri, 28 Mar 2014 01:56:08 +0100

> DHE that isn't fixable without a DOS vector being introduced.

Pardon for breaking into the conversation, but isn't the attack outlined 
here https://secure-resumption.com/ actually stopped by the 
renegotiation indication extension, contrary to what the author states 
at the page?

1. At the end of the first handshake, the finished messages of the 
connections C/A and A/S will be different.
2. The outline of the attack rests on the assumption that A might simply 
forward the messages during the second handshake, because all parameters 
are the same, and here the finished messages for C/A and A/S will 
consequently also be the same. Well, they will be if no renegotiation 
indication extension is included. If it is, this will however be 
different for C/A and A/S, and hence result in different finished 
messages after the second handshake as well.

Am I missing something obvious?

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 28 Mar 2014 07:38:47 +0100

> DHE that isn't fixable without a DOS vector being introduced.

In regard to DHE validation, one answer (already proposed on this thread) is to use well-known named groups, instead of arbitrary groups. So, rather than banning DHE, we could standardise named groups (like named curves) and ban the use of arbitrary groups (and arbitrary explicit curves).

Still, public key validation remains important for both ECDHE and DHE, and essential to prevent insecure resumption-like attacks.

> 1. At the end of the first handshake, the finished messages of the connections C/A and A/S will be different.
> 2. The outline of the attack rests on the assumption that A might simply forward the messages during the second handshake, because all parameters are the same, and here the finished messages for C/A and A/S will consequently also be the same. Well, they will be if no renegotiation indication extension is included. If it is, this will however be different for C/A and A/S, and hence result in different finished messages after the second handshake as well.

Yes, which is why the attack requires 3 handshakes not two. By injecting a resumption handshake between 1. and 2. above, the finished messages of C/A and A/S can be made the same. I’d be happy to discuss off-list.

Best,
Karthik

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Mar 2014 09:25:51 -0400

> Historically we have opted to provide ECDHE *in place of* classic DHE.

did SChannel ever support classic DHE with RSA authentication?

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx

suggests that XP and win2003 (which, afaict, were what immediately
preceded vista) does not have DHE.  So it looks like ECDHE was just
added, but "classic DHE" wasn't in SChannel in the first place, which
doesn't sound like ECDHE is "in place of" DHE to me.

or am i misreading the documentation?

	--dkg

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2014 07:09:57 -0700

On Thu, Mar 27, 2014 at 11:38 PM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> In regard to DHE validation, one answer (already proposed on this thread)
> is to use well-known named groups, instead of arbitrary groups. So, rather
> than banning DHE, we could standardise named groups (like named curves) and
> ban the use of arbitrary groups (and arbitrary explicit curves).
>

Note that we could do this for TLS 1.x not just for TLS 1.3, though
obviously we couldn't *require* standardized groups for older
versions for compatibility reasons.

WRT group validation being a DoS vector (a point made by Watson),
the effect of the DoS seems somewhat limited by the fact that it's the
server who selects the group and therefore the client who has to validate
it, so you can't push arbitrary computational load onto some server just by
connecting
to them and forcing it to validate parameters (though of course you can
already do so to some extent by forcing them to do signatures, key
exchanges, etc.)

This isn't to say that DoS of clients isn't a potentially big deal but at
least in the Web context any network attacker can force arbitrary amounts
of computation onto the client just by pushing JS into any HTTP connection
[0]. Outside the Web context, there probably are cases where this would be a
more viable attack, though depending on the cost of validation they
might require the client to also be willing to do a lot of reconnects
automatically in order to be really affected.

-Ekr

[0] And of course in Karthik's attack, the assumption is that the client
would connect to the attack server in any case and so even in an
all HTTPS world, the attacker could shove down arbitrary JS from
his own site.

Still, public key validation remains important for both ECDHE and DHE, and
> essential to prevent insecure resumption-like attacks.
>
> indication extension is included. If it is, this will however be different
> for C/A and A/S, and hence result in different finished messages after the
> second handshake as well.
>
>
> Yes, which is why the attack requires 3 handshakes not two. By injecting a
> resumption handshake between 1. and 2. above, the finished messages of C/A
> and A/S can be made the same. I'd be happy to discuss off-list.
>
> Best,
> Karthik
>
>
>

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Mar 2014 11:13:52 -0400

On Fri, Mar 28, 2014 at 10:09 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Thu, Mar 27, 2014 at 11:38 PM, Karthikeyan Bhargavan
> <[email-masked]> wrote:
>>
>>

Validating a DH group requires factoring p-1 and determining that it
has a large nonsmooth part, as well as determining p is prime.
This is a lot of work, which is why clients don't do it. (Even if we
demand that p-1 have no prime factors up to 256 bit there isn't a good
way to do that beyond factoring[1]). On my rather nice machine,
running gp and asking it to factor 2^1024-epsilon takes a long time.
The DoS is from one connection, not many.

As for Javascript, web browsers have to deal with scripts running
overtime already. It's a much easier problem.

Sincerely,
Watson Ladd

> least in the Web context any network attacker can force arbitrary amounts of
> computation onto the client just by pushing JS into any HTTP connection [0].
> Outside the Web context, there probably are cases where this would be a
>> forward the messages during the second handshake, because all parameters are
>> the same, and here the finished messages for C/A and A/S will consequently
>> also be the same. Well, they will be if no renegotiation indication
>> extension is included. If it is, this will however be different for C/A and
>> A/S, and hence result in different finished messages after the second
>> handshake as well.
>>
>>
>> and A/S can be made the same. I’d be happy to discuss off-list.
>>
>> Best,
>> Karthik
>>
>>
>>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 28 Mar 2014 19:03:25 +0000

> did SChannel ever support classic DHE with RSA authentication?

"Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update spring 2014" adds a couple of DHE_RSA cipher suites:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Without this update, schannel supports DHE_DSS (admittedly, not the most widely used auth).

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Friday, March 28, 2014 6:26 AM
To: Marsh Ray; Martin Thomson
Cc: [email-masked]
Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)

suggests that XP and win2003 (which, afaict, were what immediately preceded vista) does not have DHE.  So it looks like ECDHE was just added, but "classic DHE" wasn't in SChannel in the first place, which doesn't sound like ECDHE is "in place of" DHE to me.

	--dkg

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Mar 2014 12:55:23 -0700

As a point of reference, IKE has done well with standardized groups, and basically no one uses non-standard groups. It's not clear why TLS would be any different, given that it is the same "client offers many, server picks one" model.

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Mar 2014 11:35:57 +0100

> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Andrei, may we therefore assume that "Windows RT 8.1, Windows 8.1, and 
Windows Server 2012 R2 update spring 2014" will also add these 2 ciphers...

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256

?

(Marsh wrote "Historically we have opted to provide ECDHE *in place of* 
classic DHE".  I'm trying to figure out if this is still your approach, 
or if you're now doing the opposite!)

Thanks.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 31 Mar 2014 17:34:44 +0000

Hi Rob,

No, this update does not add new ECDHE_RSA cipher suites. However, I would not rule out the possibility of implementing TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA*384* in a future update.

(In any case, I would not read too much into "Historically we have opted to provide ECDHE *in place of* classic DHE". IMHO, both DHE and ECDHE have their place and we'll keep adding support for the cipher suites our customers need.)

Cheers,

Andrei 

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Monday, March 31, 2014 3:36 AM
To: Andrei Popov; Daniel Kahn Gillmor; Marsh Ray; Martin Thomson
Cc: [email-masked]
Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)

> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Andrei, may we therefore assume that "Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update spring 2014" will also add these 2 ciphers...

?

(Marsh wrote "Historically we have opted to provide ECDHE *in place of* classic DHE".  I'm trying to figure out if this is still your approach, or if you're now doing the opposite!)

Thanks.

> Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming 
> Consensus on removing RSA key Transport from TLS 1.3)
>

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.