Subject: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 26 Mar 2014 18:43:18 +0000

TLS has had cipher suites based on RSA key transport (aka "static RSA", TLS_RSA_WITH_*) since the days of SSL 2.0.   These cipher suites have several drawbacks including lack of PFS, pre-master secret contributed only by the client, and the general weakening of RSA over time.  It would make the security analysis simpler to remove this option from TLS 1.3.  RSA certificates would still be allowed, but the key establishment would be via DHE or ECDHE.  The consensus in the room at IETF-89 was to remove RSA key transport from TLS 1.3.  If you have concerns about this decision please respond on the TLS list by April 11, 2014.

Thanks,

Joe
[Speaking for the TLS chairs]

---

From: Rene Struik <[email-masked]>
Date: Wed, 26 Mar 2014 15:08:37 -0400

Hi Joe:

If one has concerns re "the general weakening of RSA over time", what 
about putting DHE (or, if one has more modest aspirations: DHE with MODp 
groups with short exponents) on the chopping block as well?

Best regards, Rene

On 3/26/2014 2:43 PM, Joseph Salowey (jsalowey) wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 26 Mar 2014 12:30:59 -0700

Hi Joe,

Could you explain what the process for TLS 1.3 is?

It seems like you want the group to start making lots of small,
specific decisions.  I'm not convinced that's the best way to design a
complex protocol with lots of inter-related pieces.

I was hoping we'd have some discussion on the TLS 1.3 process, now
that the charter is approved.  Is that not going to happen?

Trevor

---

From: [email-masked] (Martin Rex)
Date: Wed, 26 Mar 2014 22:12:19 +0100 (CET)

Joseph Salowey (jsalowey) wrote:
>
> TLS has had cipher suites based on RSA key transport (aka "static RSA",
> TLS_RSA_WITH_*) since the days of SSL 2.0.   These cipher suites have
> several drawbacks including lack of PFS, pre-master secret contributed
> only by the client, and the general weakening of RSA over time.
> It would make the security analysis simpler to remove this option from
> TLS 1.3.  RSA certificates would still be allowed, but the key
> establishment would be via DHE or ECDHE.  The consensus in the room
> at IETF-89 was to remove RSA key transport from TLS 1.3.  If you have
> concerns about this decision please respond on the TLS list by
> April 11, 2014.

To me that looks like a pretty bogus statement.

There really is nothing wrong with static RSA, and I can conceive a
number of scenarios where (EC)DHE could make the situation much worse.

DHE has the problem that it lacks a required set of parameters.
Generating everything anew and having to verify all parameters
on the client side for each and every handshake is prohibitively expensive,
so a number of implementations seem to be using a static keypair for the
server that is manually generated by an admin once, and never refreshed/
updated, making it appear better than static RSA, but de-facto much
worse.  Small devices that currently have poor entropy sources may
be much better off with a static RSA keypair once generated by an
 admin on a machine with good entropy and then pushed onto the device
rather then having to frequently generate new keys on such a device.

If RSA was weak, _any_single_use_ of RSA would make you "vulnerable",
not just the RSA encryption of the premaster secret, but in just the
same fashion the RSA signature on the (EC)DHE parameter in the
ServerKeyExchange handshake message.  Or the signatures on the
certificate chain, or the signatures on the OCSP responses or CRLs.

And once you do the whole PKI glory (long and complex certificate chains
and full revocation galore, then you may realize that RSA still has
a significant performance advantage over the alternatives.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Wed, 26 Mar 2014 18:34:43 -0400

> rather then having to frequently generate new keys on such a device.

If the admin is provisioning the devices, they can seed the devices
with entropy, which gets irreversibly mixed each power cycle.
But yes, DHE parameter validation is a big issue.

> certificate chain, or the signatures on the OCSP responses or CRLs.

RSA signatures in the PKI are being increased in size to 2048 and 4096
over the next few years to address this problem. This doesn't seem to
be in the cards for static RSA because of the speed issues.

> a significant performance advantage over the alternatives.

For a single signature, maybe. But for multiple signatures with the
Schnorr scheme (or ECDSA plus a single extra bit... why wasn't this
bit included?) you can batch verify. This has a significant
performance advantage.

Furthermore, this is orthogonal to the issue of the fastest TLS
handshake. RSA decryption is very slow, so you can do the two
exponentiations to complete a P256 handshake and signing in the time
to encrypt. The client doesn't matter: it is making very few
connections, so can take a while to do the calculations.

Sincerely,
Watson Ladd

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

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 26 Mar 2014 23:25:00 +0000

Martin,

While I agree with most of what you say including some benefits of RSA, the DHE parameter verification by the client while desirable is not a genuine security threat.  A rogue server has many other ways to compromise the exchange,

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Wednesday, March 26, 2014 5:12 PM
To: Joseph Salowey (jsalowey)
Cc: [email-masked]
Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

Joseph Salowey (jsalowey) wrote:
> establishment would be via DHE or ECDHE.  The consensus in the room at 
> IETF-89 was to remove RSA key transport from TLS 1.3.  If you have 
> concerns about this decision please respond on the TLS list by April 
> 11, 2014.

There really is nothing wrong with static RSA, and I can conceive a number of scenarios where (EC)DHE could make the situation much worse.

DHE has the problem that it lacks a required set of parameters.
Generating everything anew and having to verify all parameters on the client side for each and every handshake is prohibitively expensive, so a number of implementations seem to be using a static keypair for the server that is manually generated by an admin once, and never refreshed/ updated, making it appear better than static RSA, but de-facto much worse.  Small devices that currently have poor entropy sources may be much better off with a static RSA keypair once generated by an  admin on a machine with good entropy and then pushed onto the device rather then having to frequently generate new keys on such a device.

If RSA was weak, _any_single_use_ of RSA would make you "vulnerable", not just the RSA encryption of the premaster secret, but in just the same fashion the RSA signature on the (EC)DHE parameter in the ServerKeyExchange handshake message.  Or the signatures on the certificate chain, or the signatures on the OCSP responses or CRLs.

And once you do the whole PKI glory (long and complex certificate chains and full revocation galore, then you may realize that RSA still has a significant performance advantage over the alternatives.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 27 Mar 2014 00:28:27 +0100 (CET)

> connections, so can take a while to do the calculations.

When using an RSA server certificate the server can choose between having
to perform static RSA key exchange with an RSA private key (decryption)
operation on the RSA PremasterSecret or an RSA Private key (signature)
operation to sign the ServerKeyExchange handshake message
--and that signature covers ClientHello.random and ServerHello.random
so is unique per full handshake, just like the RSA decryption of the
Premaster secret.

Where exactly do you see a performance _advantage_ of an RSA-signed
(EC)DHE key exchange vs. an RSA-decrypted PremasterSecret?

-Martin

---

From: Hanno Böck <[email-masked]>
Date: Thu, 27 Mar 2014 09:55:27 +0100

On Wed, 26 Mar 2014 22:12:19 +0100 (CET)
[email-masked] (Martin Rex) wrote:

> on the client side for each and every handshake is prohibitively
> expensive, so a number of implementations seem to be using a static
> keypair for the server that is manually generated by an admin once,
> and never refreshed/ updated, making it appear better than static
> RSA, but de-facto much worse.

Appart from the other issues, I think it would make a lot of sense to
change DHE handling in TLS 1.3 away from "server can have arbitrary
parameters".
The authors of the triple handshake attack have proposed having a set
of "known good" parameters and I think this is the way to go for TLS
1.3 and DHE. It's probably enough to say "we define a 2048 and a 4096
DH parameter set with tested and known primes" and allow the option to
easily define more if there ever is a need to say "we need 8192 bit DHE
now".

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 27 Mar 2014 10:19:00 +0100

> that the charter is approved.  Is that not going to happen?

I second that.

regards,
Nikos

---

From: "Jack Lloyd" <[email-masked]>
Date: Thu, 27 Mar 2014 07:55:51 -0400

> change DHE handling in TLS 1.3 away from "server can have arbitrary

+1; it is simpler, saves handshake bytes, and prevents misconfigured
servers from doing stupid things like 512-bit DH. Something very much
like the existing EllipticCurveList (_without_ the explicit curve
option) seems like it would work well.

~Jack

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 27 Mar 2014 12:27:17 +0000

> change DHE handling in TLS 1.3 away from "server can have arbitrary

I'm wondering: why even keep DHE around at all?

Let's face it: traditional DHE runs like an absolute dog compared to ECDHE using secp256r1, or especially curve25519 (which we have a live draft for now: I'm ready to start driving deployment almost as soon as we get a curve number!).

Speed is why people were reluctant to deploy PFS, and in many cases in the wild, advised increasing TLS server performance by disabling it (which is bad for everyone). ECDHE eliminates that problem.

Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead?

Suggestion: remove static RSA *and* traditional DHE and mandate ECDHE for key exchange in TLS 1.3. I propose,
 curve25519 as mandatory-to-implement and secp256r1 as recommended-to-implement [? Also mandatory, maybe?], both in constant time, which is comparatively easy, especially for 25519.

That would simplify the protocol considerably (decreasing the code and protocol surface to audit), increase its baseline security well above 2048-bit DH, to ~3072-bit (ish) levels, reduce the size of the exchanges and massively reduce the CPU load on both servers and clients.

That seems to me like a win for every one of the good guys and none of the bad guys: TLS 1.3 gets both simpler, easier to audit, more secure *and* faster - and that's the kind of thing that'll drive 1.3 adoption in my opinion. Thoughts?

- --
/akr

---

From: "Paul Bakker" <[email-masked]>
Date: Thu, 27 Mar 2014 13:37:43 +0100

>  curve25519 as mandatory-to-implement and secp256r1 as recommended-
> to-implement [? Also mandatory, maybe?], both in constant time, which is
> comparatively easy, especially for 25519.

Let's not do that.. The world is bigger that 'Fat clients'. Other key exchanges, such as pure PSK have their value in very-low-resource situations.
And I think it's never a good idea to depend on a single key exchange scheme, for future security robustness.

> That would simplify the protocol considerably (decreasing the code and
> protocol surface to audit), increase its baseline security well above 2048-bit
> DH, to ~3072-bit (ish) levels, reduce the size of the exchanges and massively
> reduce the CPU load on both servers and clients.

I do agree that we should make the core as secure as possible, but we should keep all kinds of clients and servers in mind..

Paul Bakker

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 27 Mar 2014 12:59:02 +0000

On 27 March 2014 12:37:43 GMT+00:00, Paul Bakker <[email-masked]> wrote:

>Other key exchanges, such as pure PSK have their value in very-low-resource
>situations.

Hmm. Where you're low resource enough to have to pre-share keys, you're specifying your own profile because you know exactly what's connecting (otherwise you couldn't pre-share keys with it).

I don't think that's suitably applicable to the general profile for TLS on the internet.

Maybe, if you're that constrained, you don't *really* want TLS and its x.509 luggage at all: AES-GCM or ChaCha20-Poly1305 and a monotonic counter nonce? And if you want forward security, and you probably should, then you probably want... curve25519.

I certainly don't see how that's a good argument for keeping DHE around, which is the fattest of the key exchanges. Seems rather like the opposite, actually.

>scheme, for future security robustness.

Agreed, which is part of why I suggested ECDHE over *two* curves: djb's fast curve25519, and NIST's already-deployed and 'Suite Beatified' secp256r1. They're fairly different.

We can specify further ones in future if (and hopefully in advance of when) problems arise. Specifying several exchanges might potentially make us vulnerable to the difficulties of both, if the attacker gets to pick which. We *should* safely avoid that of course, but it should be kept in mind.

- --
/akr

---

From: Hanno Böck <[email-masked]>
Date: Thu, 27 Mar 2014 14:01:00 +0100

On Thu, 27 Mar 2014 12:27:17 +0000
Alyssa Rowan <[email-masked]> wrote:

> Let's face it: traditional DHE runs like an absolute dog compared to
> ECDHE using secp256r1, or especially curve25519 (which we have a live
> draft for now: I'm ready to start driving deployment almost as soon
> as we get a curve number!).

I'm not comfortable with the idea of going elliptic curve everywhere.
I'd really prefer to keep the "old and well tested" options around.

There's a particular reason I think so: I think at one point (which may
be 10, may be 30 years away or may not happen at all) we'll have to
deal with quantum computers. Right now we have nothing really to offer
here yet (I'm aware of pqcrypto algos, but none of them is in any usable
state right now), but the first defense to quantum computers is
increased key sizes.

It will be easier to build a quantum computer to break 512 bit keys
than one to break 4096 bit keys. That's why in a word where quantum
computers become a reality I'd rather go with RSA+DHE with large
key/modulus than with anything from the ECC family.

Appart from that: From the facts I know I am extremely uncomfortable
with both ECDSA and the NIST curves and I'd really like to have them
removed from TLS altogether. Strong vote for Ed25519 (or another
algorithm with similar properties) and only curves that pass the
safecurves criteria.

-- 
Hanno Böck
http://hboeck.de/

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 27 Mar 2014 14:12:16 +0100

Alyssa Rowan schrieb am 27.03.2014 13:27:

> curve25519 as mandatory-to-implement and secp256r1 as recommended-to-implement [? Also mandatory, maybe?], both in 
> constant time, which is comparatively easy, especially for 25519.

It is not wise to base the security of a protocol on a single computational problem and fixed key length.

- -- 
Johannes

---

From: "Paul Bakker" <[email-masked]>
Date: Thu, 27 Mar 2014 14:13:51 +0100

> Maybe, if you're that constrained, you don't *really* want TLS and its
x.509
> luggage at all: AES-GCM or ChaCha20-Poly1305 and a monotonic counter
> nonce? And if you want forward security, and you probably should, then you
> probably want... curve25519.

I don't think my advice to those developers would be to 'invent' their own
security channels. Most of them don't have the experience to do it right.
And they're bound to make mistakes that have been fixed or mitigated in TLS.
TLS as a whole is low-footprint enough with the right conditions.

Of course, the pure PSK suite does not have X.509 luggage. But that's beside
the point.

And most developers don't have a choice. While I agree that some could
better do something else, certain standards and / or certifications require
usage of TLS.

> I certainly don't see how that's a good argument for keeping DHE around,
> which is the fattest of the key exchanges. Seems rather like the opposite,
> actually.

I never said we should keep DHE around! Just that we should not mandate a
single other key exchange mechanism. I agree that DHE is fat and is not the
best of the available choices.

But things like PSK and PAKE-based key exchanges have their merits as well..

Paul Bakker

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 27 Mar 2014 14:17:44 +0100

> I'm wondering: why even keep DHE around at all?

Agility. I agree the DHE ciphersuites are problematic in TLS, but we
also need agility. A cryptographic advance in elliptic curves may not
translate to an advance in the "traditional" mod p fields, and in that
case it would be nice having fallback ciphersuites, rather than suffer
the issues of a monoculture.

Nevertheless, I find discussions on such details fruitless at this
point. I agree with Trevor that first it has to be discussed what
process will be followed in the TLS 1.3 process. From the current
discussions in the list it feels that TLS 1.3 will be 1.2 minus some
features.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Mar 2014 10:15:57 -0400

> I'm wondering: why even keep DHE around at all?

Don't put all your eggs in one basket.

> especially curve25519 (which we have a live draft for now

I really like Curve25519, but the current draft is sub-optimal in how it specifies the encoding. If we want the curve for its performance gains, then we should encode things using its native, "most natural" format. Fixing that requires a curve registry, etc.  Hopefully the CFRG or the Security AD's will help with that.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Mar 2014 11:21:39 -0400

> Don't put all your eggs in one basket.

This is a good argument for preserving DHE. However, we lose
everything when quantum computers come out. NTRU or McElise modes
would be better backups.

> I really like Curve25519, but the current draft is sub-optimal in how it specifies the encoding. If we want the curve for its performance gains, then we should encode things using its native, "most…

Integers have no natural encoding: you're complaining that one
particular fast implementation encodes them a certain way.  As for the
registry etc, there are plans, but they have stalled admit rampant
fence painting. I'll resubmit the safecurves draft and see if that
gets things going again.

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Mar 2014 11:34:17 -0400

> Integers have no natural encoding: you're complaining that one particular fast implementation encodes them a certain way.

If they have no natural encoding, then it makes sense to use the encoding in the reference implementation developed by the curve's inventor.  No?

	/r$

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 27 Mar 2014 15:01:58 -0700

> key/modulus than with anything from the ECC family.

Barely.

With my quantum cryptography hat on, I think this is a pointless thing
to design in.  If you can build a big enough quantum computer to run any
of the period-finding / hidden subgroup algorithms, then it seems
extremely likely that you have a real fault-tolerant machine with a real
memory interconnect.  At that point, the machine size scales pretty much
linearly with the size of the group.

It's a bit different if the attacker has an adiabatic machine, but I'd
be absolutely shocked if the first machine to run Shor's algorithm is
adiabatic.

--Andy

---

From: Marsh Ray <[email-masked]>
Date: Thu, 27 Mar 2014 23:55:40 +0000

-----Original Message-----
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.

- Marsh

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Mar 2014 21:22:29 -0400

> While I agree with most of what you say including some benefits of RSA, the DHE parameter verification by the client while desirable is not a genuine security threat.  A rogue server has many other…

The recent https://secure-resumption.com/ showed that one malicious
server (which a victim deliberately connects to) could use a weak
discrete log DHE group to force a client doing client-cert
authentication into signing a pre-master secret of the server operator's
choice.

The malicious server operator could then replay that pre-master secret
to another server (in a non-DHE ciphersuite), creating two sessions with
the same session id, master secret, and connection keys (they call this
an "Unknown key share attack" or UKS).

They didn't find a way to exploit a UKS directly without taking
advantage of other flaws in the TLS protocol, but if the option of using
a bad group hadn't been there, clients using DHE ciphersuites would have
been resistant to the attacks they did find.

So permitting the use of an arbitrary DL DH group whose structure is too
expensive for the client to verify is something we should try to avoid.

	--dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 28 Mar 2014 21:33:39 -0400

> change DHE handling in TLS 1.3 away from "server can have arbitrary

I agree with this.

> easily define more if there ever is a need to say "we need 8192 bit DHE

I've submitted an initial stab at a proposal for negotiated discrete log
diffie-hellman ciphersuites:

 http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00

Please send criticism and suggestions.  I've selected the primes using
roughly the same idea as RFC 3526, but rather than using pi as the
"nothing up my sleeve" number, i've used zero (another well-known
infinite sequence).  If people see problems with this or think we should
select the named groups in a different way, i'm happy to hear other
proposals.

regards,

	--dkg