Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

From: Peter Gutmann <[email-masked]>
Date: Thu, 19 Sep 2013 09:56:14 +0000

"Blumenthal, Uri - 0558 - MITLL" <[email-masked]> writes:

>I personally think that for *ephemeral* DH even 1024 bits still is enough.
>And would *much* prefer having PFS now with individual session keys at
>somewhat greater risk, over a system that is very secure and completely
>useless because nobody bothered to deploy it.

Exactly.  We don't need theoretically perfect security in ten years when we've
finished arguing about it and have upgraded every system on the planet to
support it, we just need good enough right now.  That's DH-1024, and when we
have that turned on everywhere we've got some breathing space to worry about
what to do next.

Peter.

---

From: james hughes <[email-masked]>
Date: Fri, 20 Sep 2013 23:57:39 -0700

> have that turned on everywhere we've got some breathing space to worry about

"theoretically perfect security in ten years", really? You think that 1024 is "good enough"? I do not know a single reputable source that says 1024 bit is "secure" (outside the people on this list). Not even NIST. If you are going to step forward for PFS, do it right. Raise the D-H key size to 2048. 2048 bit is required now and will give you security for only 7 years (Thank you France). 

What is wrong with having a a reasonable amount padding between what is known to be vulnerable and what is known to be secure, especially when the cost is an extra 2 milliseconds of CPU?

<rant>
It seems like the members of this list are saying 1024 is enough. Why? What is their science? Where is their proof? Repeatedly saying "We don't need theoretically perfect security" is a proof by assertion [http://en.wikipedia.org/wiki/Proof_by_assertion]. The French equivelant of NSA (number 2 in the world?) is quite capable and this is their recommendation is 2048 NOW. Clearly, the TLS standards community must be smarter to say so unequivocally that 1024 is "enough".

This sounds a lot like the same arguments that were given to the cryptographers arguing against using MD5 by certificate authorities after a collision was found.

Why does the burden of proof seem to be so high on the cryptographers to prove that an algorithm (or key size) is not secure enough? Stated differently, why must crypto community, who knows something is, or will soon be, breakable have to shame the standards bodies into reasonable action with a pie in the face  [for the non-english speakers, for a definition of "pie in the face" see http://en.wikipedia.org/wiki/Pieing]?

Maybe the assumption is that the Cryptanalysists are lunatics and we are better off ignoring them. I get that, but Is this the best thing for the internet?
</rant>

Why not a 2048 Diffie Hellman exchange? Why not even allow it to be an option?

---

From: Michael Ströder <[email-masked]>
Date: Sat, 21 Sep 2013 15:37:19 +0200

james hughes wrote:
> "theoretically perfect security in ten years", really? You think that 1024
> is "good enough"? I do not know a single reputable source that says 1024
> bit is "secure" (outside the people on this list). Not even NIST. If you
> are going to step forward for PFS, do it right. Raise the D-H key size to
> 2048. 2048 bit is required now and will give you security for only 7 years
> (Thank you France).

I personally would prefer D-H key size 2048 bit everywhere and I don't worry
about performance. (Did you ever notice that most SSL/TLS connections are
going to ad servers?)

But the problem in the context of draft-sheffer-tls-bcp is that existing
implementations do not support D-H key size of 2048 bits. And the author(s) of
this draft take this fact to rule out DH completely and recommend EC-based
cipher suites. IMHO ECs seem to be a can of worms. I don't trust those
complicated cipher suites.

Ciao, Michael.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 21 Sep 2013 09:42:05 -0700

James,

The problem is that there apparently is lots of TLS code which can only handle
1024-bit DH parameters and would break if a server sent larger parameters.

The idea that 1024 is big enough stems from the fact that many many connections
don't use DH at all, and would benefit if RSA was replaced by EDH.  Thus an
attacker would need to break 1024-bit DH for each connection of interest.

Remember that this is an Engineering group (the "E" in IETF) which has to keep
the Internet working while we attempt to improve security for everyone.  If we
knew how to move to 2048 bits without breaking anything we would.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Sep 2013 19:15:31 +0000

> attacker would need to break 1024-bit DH for each connection of interest.

Many websites cannot deploy 2048-bit EDH because of limitations in their software, and those who can won't, because of interop issues with many of the browsers that are out there.

OTOH 2048-bit RSA keys work well pretty much everywhere. So we're left with three choices:

 1. 2048-bit RSA keying. That's good security, but no forward secrecy.
 2. 1024-bit EDH, which gives forward secrecy, but may be breakable now or in 5 years.
 3. 256-bit ECDH, which gives forward secrecy, but some people feel uneasy about.

There are good arguments for and against each of these. I don't think we have a measure of whether it's easier to compromise a single RSA private key, or to calculate the DL for several 1024-bit EDH. I don't like how #1 creates an attractive, shiny target for attackers - a single file stolen from a web server, and all the traffic can be decrypted in Wireshark. OTOH assuming that an agency such as the NSA or French equivalent is able to break any 1024-bit EDH (that's not a given) they will be able to decrypt any single connection that they would like, but I don't believe they have the resources to decrypt every one. That's good for people who are not near the top of the list of threats to national security, but kind of not so good for those who are.

As I've said before, I'd rather we chose #3.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 22 Sep 2013 00:43:36 +0300

Hi James, Michael,

please read the section we just added to -01, 
http://tools.ietf.org/html/draft-sheffer-tls-bcp-01#section-4.4. In 
particular the last sentence.

Thanks,
	Yaron

On 09/21/2013 04:37 PM, Michael Ströder wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Sep 2013 23:21:14 +0100

Hi Yaron,

Thanks again for the draft. Without any hats, I think the
WG should adopt it too. (With a hat, if they don't, then I'd
AD sponsor it, and so I bet would Sean, but doing this makes
so much sense I bet the WG do adopt it:-)

I'd suggest merging 4.1 and 4.4, since setting out the set
of ciphersuites and the issues faced is really the meat of
the whole thing.

However, regardless of hows its organised, I'd have no
problem if the meat of the recommendation was
"use 1) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or
2) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256" plus some guidance
as to good lengths for everything that can vary.

On the DHE length, I think a bit more information would be
useful if we can get it - exactly which clients or servers
have problems if DH values longer than 1024 are used? (Sorry
if I missed that earlier.)

But I'm firmly in the camp that thinks that 1024 DHE used
now is worthwhile and better than no PFS.

S.

---

From: Patrick Pelletier <[email-masked]>
Date: Sat, 21 Sep 2013 16:44:22 -0700

> 1024-bit DH parameters and would break if a server sent larger parameters.

Doesn't this "lots of TLS code" boil down to just Java?  That's the only 
implementation I've heard of that supports DHE_RSA but chokes on 2048 
DH.  Is there another?

My understanding of the Windows (SChannel) situation is that Windows has 
a limit of 1024 for DHE_DSS, but doesn't support DHE_RSA at all. 
Although it's unfortunate in some ways that it doesn't support DHE_RSA, 
it's actually a good thing in disguise, since it means that the cipher 
suite negotiation will take care of the problem.

> knew how to move to 2048 bits without breaking anything we would.

We *do* know how to move to 2048 bits without breaking anything: add an 
extension to negotiate DH size, just like how ECC curves are negotiated. 
  Although yes, this will take a while to deploy universally, it at 
least means early adopters can start using 2048 now, without breaking 
the stragglers like Java.

(I'd rather just leave Java in the dust and switch to 2048 now.  But if 
we really want to avoid breaking Java, this is how to do it.)

--Patrick

---

From: Yoav Nir <[email-masked]>
Date: Sun, 22 Sep 2013 04:00:02 +0000

On Sep 22, 2013, at 2:44 AM, Patrick Pelletier <[email-masked]> wrote:

> Doesn't this "lots of TLS code" boil down to just Java?  That's the only implementation I've heard of that supports DHE_RSA but chokes on 2048 DH.  Is there another?

There's also Apache, the most common web server on the web, that doesn't have configuration parameters for EDH key lengths, and tells OpenSSL to use 1024 bits.

> My understanding of the Windows (SChannel) situation is that Windows has a limit of 1024 for DHE_DSS, but doesn't support DHE_RSA at all. Although it's unfortunate in some ways that it doesn't support DHE_RSA, it's actually a good thing in disguise, since it means that the cipher suite negotiation will take care of the problem.
> 
> We *do* know how to move to 2048 bits without breaking anything: add an extension to negotiate DH size, just like how ECC curves are negotiated.  Although yes, this will take a while to deploy universally, it at least means early adopters can start using 2048 now, without breaking the stragglers like Java.

Perhaps it would be better to have the client suggest the actual group rather than bit length in that case. Perhaps we could reuse the IKE numbering of groups, or else have the client specify it similar to ServerDHParams struct.

> (I'd rather just leave Java in the dust and switch to 2048 now.  But if we really want to avoid breaking Java, this is how to do it.)

There's lots of Java code out there, and servers have no control over what clients access them. Unfortunately, people tend to stay with old JVMs for a long time.

Yoav

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 21 Sep 2013 21:46:52 -0700

> Perhaps it would be better to have the client suggest the actual group rather than bit length in that case. Perhaps we could reuse the IKE numbering of groups, or else have the client specify it si…

If the client chooses, then I'd prefer they choose from a list of
standardized groups similar to RFC 3526 rather than requiring the
server to (try to) verify that the parameters are usable.  We could
also sneak in a 256-bit q parameter to speed up the computations.

Mike

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 22 Sep 2013 08:34:22 +0300

It's not "only" Java, it's Windows (Internet Explorer), too. See 
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html, 
last paragraph.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 22 Sep 2013 08:38:55 +0300

I'm all for negotiating DH parameters. Life would have been much easier 
if we had it in TLS today.

But new extensions are out of scope for draft-sheffer-tls-bcp. We need a 
set of best common practices that people can actually deploy within the 
coming year, hopefully earlier.

Thanks,
	Yaron

On 09/22/2013 07:46 AM, Michael D'Errico wrote:
>>> We *do* know how to move to 2048 bits without breaking anything: add
>>> an extension to negotiate DH size, just like how ECC curves are
>>> negotiated.  Although yes, this will take a while to deploy
>>> universally, it at least means early adopters can start using 2048
>>> now, without breaking the stragglers like Java.
>>
>> Perhaps it would be better to have the client suggest the actual group
>> rather than bit length in that case. Perhaps we could reuse the IKE
>> numbering of groups, or else have the client specify it similar to
>> ServerDHParams struct.
>

---

From: Ralph Holz <[email-masked]>
Date: Sun, 22 Sep 2013 15:04:02 +0200

Hi Michael, all,

> implementations do not support D-H key size of 2048 bits. And the author(s) of

This is not true. DHE-1024 is the second option in the draft, but 2nd
and 3rd option are described in 4.4, not 4.1. I agree with Stephen
Farell that 4.1 and 4.4 should be merged.

It seems a certain consensus has been reached concerning what can be
easily deployed and what is supported by OS. ECDHE and DHE-1024 seem to
be roughly on the same level, with different problems of their own,
while DHE-2048 is hard to deploy. And we do not want RSA without PFS.

The remaining question, in my opinion, is only whether
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 should be the only "best practice"
or whether TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 should be mentioned as an
equivalent alternative.

I am still undecided on this issue. Heninger et al. have shown last year
what can happen if you have poor entropy in your devices, and they also
gave advice that programmers should not use the non-blocking RNG on
Linux devices. Won't keep programmers from doing it. Similarly, I remain
doubtful about EC implementations.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: james hughes <[email-masked]>
Date: Sun, 22 Sep 2013 07:41:13 -0700

> On Sep 22, 2013, at 6:04 AM, Ralph Holz <[email-masked]> wrote:
> 
> Hi Michael, all,
> 

A clearer statement in the draft about what the implementation should do would be enabled by the merging of these sections.

> while DHE-2048 is hard to deploy. And we do not want RSA without PFS.

Parameter negotiation seems to be a reasonable (obvious?) bridge to higher levels of security. The fact that the server (or the client, and even sometime a MITM) can reject these higher key lengths seems to be OK with me, the client can choose that to fail a connection instead of accepting being downgraded. Even if this results in additional round trips, this would be something that people will work at removing.

The following is probably a naïve attempt at a compromise.

To do a better job of "future proofing" the protocol, why aren't we talking about the key length negotiation of ECDHE? Stated differently, why is the key length hard coded at 256 with the curves being negotiated? Isn't that what got us into this mess?

If we want to stay with negotiating the complete cypher suites (which I think is a good thing to avoid ISAKMP style negotiation hell) why not put the key sizes in the suites like we do for AES and SHA?

We can define two new ones 
TLS_ECDHE256_RSA2048_GCMAES128_SHA256
TLS_DHE2048_RSA2048_GCMAES128_SHA256

And create an alias for the existing DHE using 1024 as TLS_DHE1024_RSA1024_GCMAES128_SHA256.

Naming is one of the two hardest things in Computer Science.

Again, I apologize if this is an overly simplistic solution.

---

From: Ralph Holz <[email-masked]>
Date: Sun, 22 Sep 2013 16:52:22 +0200

Hi,

> Parameter negotiation seems to be a reasonable (obvious?) bridge to
> higher levels of security. The fact that the server (or the client,
> and even sometime a MITM) can reject these higher key lengths seems
> to be OK with me, the client can choose that to fail a connection
> instead of accepting being downgraded. Even if this results in
> additional round trips, this would be something that people will work
> at removing.
> 

[...]

That wouldn't be the scope of the BCP. As Yaron has stated, the aim is a
recommendation that can be followed with what we have, striking a
compromise between PFS (near-must), support in software, and security of
AES. We leave the definition of new extension, or use thereof, to other
drafts.

When we're talking about other ciphers, I'd personally much rather see
Peter's proposal of encrypt-then-MAC, although not as an extension, please.

Ralph

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 22 Sep 2013 23:28:50 +0200

On 09/21/2013 08:57 AM, james hughes wrote:

> "theoretically perfect security in ten years", really? You think that
> 1024 is "good enough"? I do not know a single reputable source that
> says 1024 bit is "secure" (outside the people on this list). Not even
> NIST. If you are going to step forward for PFS, do it right. Raise
> the D-H key size to 2048. 2048 bit is required now and will give you
> security for only 7 years (Thank you France).
[...]
> Why does the burden of proof seem to be so high on the cryptographers
> to prove that an algorithm (or key size) is not secure enough? Stated
> differently, why must crypto community, who knows something is, or
> will soon be, breakable have to shame the standards bodies into
> reasonable action with a pie in the face  [for the non-english
> speakers, for a definition of "pie in the face" see
> http://en.wikipedia.org/wiki/Pieing]?

I couldn't agree more. The fact that 1024-bits is the only option in
some implementation that doesn't make it the best practice. It was the
best practice 13 years ago.

What would be reasonable would be to keep 2048 as the recommended value
(so the implementations with issues have an incentive to fix) and
additionally mention the issues that some implementations have, and
recommend that if short term protection is sufficient 1024-bit DH groups
offer better compatibility. Mentioning anything else than that will
mislead non-crypto experts (all key length studies list 1024-bit DH
groups as suitable for short-term data protection, nothing more).

regards,
Nikos

---

From: Patrick Pelletier <[email-masked]>
Date: Sun, 22 Sep 2013 21:16:23 -0700

> doubtful about EC implementations.

Possibly off-topic for TLS list, but: I don't think the answer is quite 
as simple as "use /dev/random" instead of "/dev/urandom".  The issue is 
only at boot time.  Once the system has been seeded with sufficient 
entropy, /dev/urandom is fine, because the entropy doesn't actually get 
"used up."  Search for "crying wolf" in the Heninger paper.

Perhaps the answer is to check the uptime, and use /dev/random if the 
system has been up for less than 3 (or 5, or something) minutes, and use 
/dev/urandom otherwise.

This has been discussed extensively in the "random vs urandom" thread on 
the randombit cryptography list last month.

--Patrick

---

From: Patrick Pelletier <[email-masked]>
Date: Sun, 22 Sep 2013 21:27:09 -0700

> http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html,

Yes, that's one of the sources I've been using, but I guess I'm 
interpreting it differently than you are.  My reading is based on the 
last sentence of that last paragraph, "IE does not support DHE in 
combination with RSA, and will never negotiate a DHE suite, anyway."

So, my interpretation is that the 1024-bit limit only applies to DSS in 
IE.  Since IE doesn't support DHE_RSA, the 1024-bit limit doesn't matter 
there.  So yes, that means you can't actually use DHE_RSA with Internet 
Explorer (regardless of bit length), but the important point is that it 
doesn't hurt for the server to support DHE_RSA, since IE won't offer it. 
  This is in contrast to the Java situation, where Java will offer 
DHE_RSA, the server will choose it, and then Java will bail because it 
doesn't support the DH length.  This results in a failed handshake, 
while the Windows situation doesn't.

--Patrick

---

From: Patrick Pelletier <[email-masked]>
Date: Sun, 22 Sep 2013 21:37:21 -0700

> There's also Apache, the most common web server on the web, that doesn't have configuration parameters for EDH key lengths, and tells OpenSSL to use 1024 bits.

I view the Apache situation as an entirely different thing, since it's 
on the server side, rather than the client side, and the server is the 
one who gets to choose the parameters in the first place.  If the BCP 
says "you should configure your server to use 2048 bits" and the server 
only supports 1024 bits, then the sysadmin will just configure it to use 
1024 bits, and we'll be no worse off than if the BCP had said to use 
1024 bits.  The point is that this doesn't actually break anything.

This is in contrast to the situation where the server picks 2048 bits, 
and the *client* only supports 1024 bits.  In that case, the handshake 
will fail.  So I see the Java (client side) issue as much worse than the 
Apache (server side) issue.

Also, of course, this is easy to fix, since one can recompile Apache to 
support larger DH:

http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

(Hey, this isn't any worse than suggesting that everyone on Red Hat 
needs to recompile to get ECC support.)

It's also worth pointing out that technically this is an issue with 
mod_ssl, not with Apache itself.  You could always use mod_gnutls instead.

--Patrick

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Sep 2013 05:21:53 +0000

On Sep 23, 2013, at 7:37 AM, Patrick Pelletier <[email-masked]> wrote:

> I view the Apache situation as an entirely different thing, since it's on the server side, rather than the client side, and the server is the one who gets to choose the parameters in the first place.  If the BCP says "you should configure your server to use 2048 bits" and the server only supports 1024 bits, then the sysadmin will just configure it to use 1024 bits, and we'll be no worse off than if the BCP had said to use 1024 bits.  The point is that this doesn't actually break anything.

Some people are suggesting that clients break the connection if offered a 1024-bit group. It does make sense that they would break the connection if offered, say, a 512-bit group, no?

> This is in contrast to the situation where the server picks 2048 bits, and the *client* only supports 1024 bits.  In that case, the handshake will fail.  So I see the Java (client side) issue as much worse than the Apache (server side) issue.
> 
> Also, of course, this is easy to fix, since one can recompile Apache to support larger DH:
> 
> (Hey, this isn't any worse than suggesting that everyone on Red Hat needs to recompile to get ECC support.)

No, it's different asking a vendor to change something vs asking end users to recompile Apache.

> It's also worth pointing out that technically this is an issue with mod_ssl, not with Apache itself.  You could always use mod_gnutls instead.

You can, but then hardly anyone does.

Yoav

---

From: Patrick Pelletier <[email-masked]>
Date: Sun, 22 Sep 2013 23:43:07 -0700

On Sep 22, 2013, at 10:21 PM, Yoav Nir wrote:

> Some people are suggesting that clients break the connection if  
> offered a 1024-bit group. It does make sense that they would break  
> the connection if offered, say, a 512-bit group, no?

True, I think it's reasonable to break the connection for 512, but not  
for 1024.  1024 is "not great security, but not utterly laughable,  
either," so the client ought to accept 1024 if the server offers it.

> users to recompile Apache.

I think the difference is that the mod_ssl issue is just a matter of  
inertia and might eventually be fixed upstream, while the Red Hat ECC  
position is an institutional policy formulated by lawyers, and is  
unlikely to change.

--Patrick

---

From: [email-masked] (Martin Rex)
Date: Mon, 23 Sep 2013 18:22:21 +0200 (CEST)

> coming year, hopefully earlier.

Personally, I believe that the cipher suites currently listed
in the document are *FAR* from realistic.

They're based on _several_ flawed assumptions:
  1) that optional EC crypto is available in deployed implementations
  2) that optional TLSv1.2 is available in deployed implementations
  3) that optional AES-GCM is available in deployed implementations
  4) that TLS clients universally have re-connect fallbacks to
     cope with TLS servers that are TLSv1.2-intolerant.

For a huge number of communication scenarios, all 4 of this list
apply only to one side, for a non-marginal, all 4 of this apply
to neither side.

Please do not underestimate problem (4).  There are currently
SSL accellerators sold (and widely used) that are limited to
TLSv1.0 and will abort connections when ClientHello contains
TLSv1.1 or TLSv1.2.  This year, the fiscal authority of Portugal (IRS)
launched Web-Services scenarios, where such TLSv1.2-intolerant
SSL Accelerators are being used in production.

What I really would appreciate is a recommendation that works
in the real world, providing a path forward that is realistic
to get added through a software update to *EXISTING* implementations,
which clearly rules out all 4 on the above list.

-Martin