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

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Sep 2013 09:54:12 +0000

Yaron Sheffer <[email-masked]> writes:

>Please see the later discussion, in particular
>http://www.ietf.org/mail-archive/web/tls/current/msg09924.html.

I've been following the discussion, but none of it really supports going to
2048 rather than just 1280 or 1536.  In addition, as Yoav pointed out, there's
a big different between solving the DLP in 1024 bits and stealing an any-size-
you-want long-term RSA key.

Peter.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Sep 2013 13:07:58 +0300

Hi Peter,

I fully agree that PFS is indeed important. There are multiple issues 
with MODP DH in TLS (performance is just one of them). So I'd like to 
recommend EC DHE instead - which makes this discussion moot.

Thanks,
	Yaron

On 09/18/2013 12:54 PM, Peter Gutmann wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Michael Ströder" <[email-masked]>
Date: Wed, 18 Sep 2013 16:21:49 +0200

On Wed, 18 Sep 2013 13:07:58 +0300 Yaron Sheffer <[email-masked]> wrote
> There are multiple issues 
> with MODP DH in TLS (performance is just one of them).

Could you please elaborate on this.

Ciao, Michael.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Sep 2013 17:27:17 +0300

Hi Michael,

please see my mail message that started this thread, way back on Sunday :-)

http://www.ietf.org/mail-archive/web/tls/current/msg09903.html

Thanks,
	Yaron

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 18 Sep 2013 12:13:48 -0400

I believe that for ephemeral DH 2048 bits is a huge overkill. In fact, 1536 is likely to be an overkill as well. I think 1280 bits would be sufficient for the next few years, and perhaps ECC patents will expire by then? In any case, I'd vote against anything (ephemeral DH-related :) larger than 1536 bits.

TNX!

P.S. It should be obvious that PFS is *far* more important than protecting one session key.
--
Regards,
Uri               <[email-masked]>

---

From: james hughes <[email-masked]>
Date: Wed, 18 Sep 2013 09:45:51 -0700

> P.S. It should be obvious that PFS is *far* more important than protecting one session key.

Please read my posting of 9/10. 2048 is required now. In this case it seems that the French government is providing sound advice. 

On Sep 10, 2013, at 9:00 AM, james hughes <[email-masked]> wrote:

> Lastly, going a partial step seems strange also. Why do we what to put ourselves through this again so soon? The French government suggests 2048 now (for both RSA and DHE), and will only last 6 years. From 
> 	http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf
> 
>> La taille minimale du module est de 2048 bits, pour une utilisation ne devant pas depasser lannee 2020.
> The minimum size of the modulus is 2048 bits for use not to exceed 2020.
> 
>> Pour une utilisation au-dela de 2020, la taille minimale du module est de 4096 bits
> For use beyond a 2020, the minimum module size is 4096 bits
> 
> 
> Pardon the bad cut/paste and google translate, but I believe you get the point.

---

From: james hughes <[email-masked]>
Date: Wed, 18 Sep 2013 10:13:54 -0700

On Sep 18, 2013, at 9:13 AM, "Blumenthal, Uri - 0558 - MITLL" <[email-masked]> wrote:

> I believe that for ephemeral DH 2048 bits is a huge overkill. In fact, 1536 is likely to be an overkill as well. I think 1280 bits would be sufficient for the next few years,

Why are we suggesting something that will be sufficient for the next few years? IMHO, it will take a few years to implement this change. By the time this has been adopted, will be in trouble again.

>  and perhaps ECC patents will expire by then? 

But the trust in ECC will not have recovered by then.

Is the complaint speed?  We are arguing about a key exchange that goes from ~1ms to ~3ms. Yes, this is more but this is absolutely not a problem for PCs or even phones or tablets especially in the light of session keep alive and other techniques that allow a key exchange to last a while. 

On Sep 9, 2013, at 7:30 PM, Michael Ströder <michael at stroeder.com> wrote:

> MBA-2:tmp synp$ openssl speed dsa1024 dsa2048
[…]
>                  sign    verify    sign/s verify/s
> dsa 1024 bits 0.000445s 0.000515s   2247.6   1941.8
> dsa 2048 bits 0.001416s 0.001733s    706.4    577.2

Is the complaint that the server load is too high? 

Why are you suggesting such a partial step in light of Moore's law? If 1024 is not large enough, how long will 1200 last? Do we think that Moore's law is not relevant (massively parallel operations already dominate the time to recover a key, so single thread performance is a moot point). Do you assume that the value of data goes down so fast that using a key that will be easy to recover in 5 years is "good enough"?

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 18 Sep 2013 13:34:31 -0400

> Why are we suggesting something that will be sufficient for the next few years? IMHO, it will take a few years to implement this change. By the time this has been adopted, will be in trouble again.

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.

> But the trust in ECC will not have recovered by then.

I trust ECC. My only problem with it is its set of patents. Whoever doesn't trust ECC - feel free to go to 10K RSA keys. :-)

> Is the complaint speed?  We are arguing about a key exchange that goes from ~1ms to ~3ms. Yes, this is more but this is absolutely not a problem for PCs or even phones or tablets especially in the…

What about servers? An individual PC (and its user :) with one TLS connection can afford 30 seconds of session establishment time, no big deal. A server might not like it.

> Is the complaint that the server load is too high? 

It probably is. But I'll let Michael speak for himself. ;)

> Why are you suggesting such a partial step in light of Moore's law? If 1024 is not large enough, how long will 1200 last? Do we think that Moore's law is not relevant (massively parallel operations…

To repeat myself, I personally think that 1024 bits is large enough for *ephemeral* DH. And yes, I assume that value of individual sessions would go down fast enough, faster than the ability to scoop them all and crack in bulk. So with PFS, an ordinary session's security lifetime of 5 years (please note, that we don't know whether in 5 years 1024-bit DH would be crackable that easily, let alone 1280) would be fine with me. If you think that in 5 years 1024-bit DH will be trivially crackable - I'd like to see some evidence to support it.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 18 Sep 2013 20:25:12 +0200

James,

you got the citation wrong:

> Is the complaint that the server load is too high? 

Numbers above were provided by Yoav as follow-up to my question. [1]

Personally I'm not scared by server load.

Ciao, Michael.

[1] http://www.ietf.org/mail-archive/web/tls/current/msg09836.html

---

From: Michael Ströder <[email-masked]>
Date: Wed, 18 Sep 2013 20:46:00 +0200

> http://www.ietf.org/mail-archive/web/tls/current/msg09903.html

Reading this posting your main objections against MODP DH are interop issues
of today's implementation. Right? This leads me to a more general question...

First, I really appreciate that you write down this BCP document.
But I wonder what the exact scope should be.

In the abstract you say "existing standards and implementations", I guess to
exclude approaches yet to be defined in a new standard. Agreed.
But does that also exclude pushing implementors to slightly improve their
software? The "deployers rather than for implementers" in the introduction
sounds like it.

If that's the scope you're stuck into recommending the least common
denominator of today's implementations and implementors can take your RFC as
excuse to stop improving their implementations.
Also you're in the trap of choosing "widely-used" implementations for your
"Implementation Status" section which is always questionable depending on
personal deployments, especially since the main focus now seems to be web
servers and browsers.

Frankly I have no idea how to get out of this though.

Ciao, Michael.

---

From: james hughes <[email-masked]>
Date: Wed, 18 Sep 2013 12:15:51 -0700

On Sep 18, 2013, at 10:34 AM, "Blumenthal, Uri - 0558 - MITLL" <[email-masked]> wrote:

> If you think that in 5 years 1024-bit DH will be trivially crackable - I'd like to see some evidence to support it.

There is a different between "trivially crackable" and routinely exploitable. In 5 years this will be routinely exploitable. 

It seems to me that the standards process does not need NSA to subvert the process, the standards people seem to be doing this fine by themselves. Anyway, speaking as someone working in this field (more factoring than discreet log) the professional recommendation is 2048. 

I am not baiting here, but the argument that 2048 is "too much" given that a PC can do a complete authenticated PFS key exchange in 3ms of CPU time seems "interesting".

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 18 Sep 2013 15:24:18 -0400

From:  james hughes <[email-masked]>
> There is a different between "trivially crackable" and routinely exploitable.
> In 5 years this will be routinely exploitable.

If you mean "exploitable in bulk", then I'd buy your argument.  (Though
we've no idea what may happen in 5 years.)

> It seems to me that the standards process does not need NSA to subvert the
> process, the standards people seem to be doing this fine by themselves.
> Anyway, speaking as someone working in this field (more factoring than
> discreet log) the professional recommendation is 2048.

Recommendation noted. I almost remember myself many years ago trying to
convince SNMP WG that HMAC is a better choice than just keyed hash, and
SHA-1 should replace MD5 as "MUST". The arguments against it were "it would
hurt performance too badly".

> I am not baiting here, but the argument that 2048 is "too much" given that a
> PC can do a complete authenticated PFS key exchange in 3ms of CPU time seems
> "interesting". 

As I said, if the exchange takes 3 seconds on my PC (or on my smartphone :)
I'm OK with it. The complaints are likely to come from the server folks. You
can guess why.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Sep 2013 19:46:57 +0000

On Sep 18, 2013, at 10:15 PM, james hughes <[email-masked]<mailto:[email-masked]>>
 wrote:

On Sep 18, 2013, at 10:34 AM, "Blumenthal, Uri - 0558 - MITLL" <[email-masked]<mailto:[email-masked]>> wrote:

Based on what? There's been a paper ([1]) describing how to produce a SHA-1 collision in 2^61 steps for two years, and nobody's produced a collision yet. This should be within the powers of a moderately well-funded company or university, not just government agencies. Sure, the NSA has the resources to produce a SHA-1 collision. But if they had to produce one for *each* session they wanted to break, they would have to be very picky with choosing the sessions that they break.

1024-bit RSA and DSA are usually considered equivalent to 80-bit security, so half a million times more difficult to crack than producing a SHA-1 collision (an effort no civilian has yet dared to take). DHE with 1024-bit keys means that our favorite pervasive attacker would need that much effort to crack a single connection. It's much better to deploy that than to not deploy 2048-bit DHE because so many of the servers and clients don't support it.

Yes, and where it's possible (RSA keys) we've all migrated. But the professional recommendation that I'm hearing is to move to ECC.

Moving from 1 ms to 3 ms is trivial for a client, but may require buying more hardware for the server. As someone in the field of selling hardware, that's great! But it does slow adoption.

But that is not the argument you hear from me. My argument is that it's pointless to change implementation to support a better DHE, when (a) the current DHE implementation is OK for now, and (b) ECDHE is the future and already implemented in most codebases.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Sep 2013 23:32:50 +0300

Hi Michael,

Please see below.

	Yaron

> software? The "deployers rather than for implementers" in the introduction

This is just my personal opinion (as long as this doc has not been 
adopted by the working group). But I think we are in violent agreement. 
I do not want to depend on any new standards, extensions etc., because 
this could take forever. I do want to be aware of existing 
implementations as a *baseline*, but definitely to help steer the 
industry in a direction that will improve the overall security of the 
Internet. So, I include a table listing existing implementations, so 
that we know what the current situation is. But I certainly am *not* 
pushing towards a least common denominator of today's implementations 
(which would be TLS 1.0, alas).
> personal deployments, especially since the main focus now seems to be web

I don't understand this point. Browsers and Web servers are obviously 
important, probably the most important "customers" of this document. 
Moreover, other uses (such as Web services) are IMHO much easier to 
improve. Taking as an example the Amazon Web Services set of RESTful 
APIs, they would have a much easier time migrating the finite number of 
SDKs that access them towards more secure TLS, compared with a general 
purpose Web server like Yahoo!.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 18 Sep 2013 14:10:50 -0700

>Frankly I have no idea how to get out of this though.

I would address the issue of DHE keys that are limited to 1024 
bits by saying that the use of 1024 bits is the best current 
practical practice. I would also follow that recommendation with 
a note that 1024 bits is smaller than the best current practice, 
but is the limit provided by current implementations, so 
following the best current practice will change when 
implementors get off their butts.

A section in the document listing some of the implementations 
that can't perform to best current crypto practice and where 
they are deficient might also be a useful goad.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | Re: Computer reliability, performance, and security:
408-356-8506       | The guy who *is* wearing a parachute is 
*not* the
www.pwpconsult.com | first to reach the ground.  - Terence Kelly

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Sep 2013 03:33:04 +0200 (CEST)

> you-want long-term RSA key.

The TLS WG could have easly provided an adequate PFS solution
many years ago that could be trivially enabled for all existing
implementations.  Ephermeral RSA.  99% of the code is already
present in all implementations, because this is used in the
RSA_EXP cipher suites.

  http://www.ietf.org/mail-archive/web/tls/current/msg01541.html

(EC)DHE is a mess, because both, servers and clients will regularly
have to regenerate new keys, and there are going to be severl 
different keys necessary for the preferences of various servers
and sometimes, the client-side key generation will have to be
performed inline.  How many different keys will clients need
for ECDHE?

With Ephemeral RSA, only the server has to generate the temporary
RSA keypair, and can *ALWAYS* generate the ephemeral RSA keypair out-of-band.

I'm not a cryptographer, but I'm actually not convinced that
counter modes of AES are a road I want to travel.  (I'm wondering:
do we actually know the length of the cycles of AES in counter mode?
Is there a paper describing what assumption the security of counter
modes are based on, and formal proofs that AES actually has all
these properties?)

I have not yet seen anything worrisome about AES-CBC.  And the
CBC padding oracle that Vaudenay complained about could have
trivially been fixed in TLSv1.1 already, since the problem, and
its solution, were described in Vaudenay's paper.  We can still
fix it with Peter's proposal. 

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Sep 2013 04:06:42 +0200 (CEST)

> RSA keypair, and can *ALWAYS* generate the ephemeral RSA keypair out-of-band.

What I had not remembered from the past discussion, and just
found in a later reply from EKR:
   http://www.ietf.org/mail-archive/web/tls/current/msg01556.html

was the design "feature" (I believe it is a defect), that
the ephemeral key exchange in the server key exchange handshake
message exists only in a an exteremely paranoid variant, requiring
an additional private key operation for every handshake.

It would really help if client and server could negotiate the use
of alternative "signed parameters format" for ephemeral (RSA) keys
that do not require a seperate signature (=private key operation)
for each handshake, but where the signed parameters could be reused
for several hours, maybe using a time-based indicator for the
freshness of the ephemeral keypair.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Sep 2013 04:47:03 +0200 (CEST)

> modes are based on, and formal proofs that AES actually has all

I should have first read what counter mode actually means,
such as http://tools.ietf.org/html/rfc3686#section-2

I'm sorry.

-Martin

---

From: james hughes <[email-masked]>
Date: Wed, 18 Sep 2013 22:54:26 -0700

> On Sep 18, 2013, at 7:47 PM, [email-masked] (Martin Rex) wrote:
>> 

Hmmm, I am, and, yes, we do. It is a well known proven fact that a properly chosen IV with a symmetric block cipher is full length, in that it is 2^128 blocks (for 128 bit AES) before recycling. I have a question for you... Do you have the patience to understand what "properly chosen" really means? 

This is a serious question.

I realize that there are a lot of politics within the TLS community that "real" cryptographers are not willing to play, and I may well be one of those whom you will wash away... 

Do you really want to hear, or are your own sound bites enough?