Subject: [TLS] Fresh results

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Dec 2015 14:28:49 -0500

https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf

This one looks very nasty to fix. Short of disallowing the use of RSA
certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I
don't see a good fix. I haven't read this paper in detail yet.

Cross-protocol attacks are the gift that keeps giving.

Sincerely,
Watson

---

From: Hanno Böck <[email-masked]>
Date: Tue, 1 Dec 2015 21:02:57 +0100

On Tue, 1 Dec 2015 14:28:49 -0500

> Cross-protocol attacks are the gift that keeps giving.

Correct me if I'm wrong, but as I understand the result (and I had one
of the authors explaining it to me a few days ago) the problem appears
only if you have a TLS 1.2 implementation with an RSA keyexchange that
is vulnerable to a bleichenbacher attack. If it is not then you're fine.

So as long as you make sure you implement all the proper
countermeasures against that you should be fine. (Granted: This is
tricky, as has been shown by previous results, even the OpenSSL
implementation was lacking proper countermeasures not that long ago,
but it's not impossible)

Deprecating the RSA keyexchange just became a bit harder with Google's
intent to deprecate DHE in Chrome and use RSA as the fallback if the
host doesn't do ECDHE.

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

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

---

From: Dave Garrett <[email-masked]>
Date: Tue, 1 Dec 2015 18:56:36 -0500

> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf

This analysis was done against TLS 1.3 draft 07 from July. It changed to RSA-PSS signatures for handshake messages in draft 09. (current is draft 11; draft 12 is pending) This doesn't seem to change anything, though. QUIC also uses PSS.

> don't see a good fix. I haven't read this paper in detail yet.

I think it's reasonable at this point to publish a diediedie RFC for plain RSA use in all TLS versions and mandate expectation of (EC)DHE with RSA (or any certificate) everywhere. This technically wouldn't apply to IE6 on XP, as that's generally using SSL3, which already got its diediedie (MS left TLS 1.0 off by default forever; anyone who can fix that can install something less than 15 years old). IE7+ on Vista+ & Java 6+ support FS RSA cipher suites.

> Cross-protocol attacks are the gift that keeps giving.

Or, yet another lesson that just deprecating old features with new protocols is not enough. Keeping known-weak features around forever for backwards compatibility always seems to hurt you eventually.

Dave

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 02 Dec 2015 11:14:41 +0100

> is vulnerable to a bleichenbacher attack. If it is not then you're

The interesting result of the paper is:
"Even though this limits the
practical  impact  of  this  attack,  it  demonstrates  that  simply
removing a legacy algorithm from a standard is not necessarily
sufficient to protect against its weaknesses."

Even though the attack does not work for current implementations it
underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't get
any advantage from the better algorithms in TLS 1.3. You are as safe,
as if you'd be using TLS 1.2.

That can be claimed to be trivial result given that it is underlined on
almost every paper that describes a cross-protocol attack, but it is
not still grasped by the engineering community. There have been
described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5
by Yu et al., TLS between ciphersuites starting by Wagner and
Schneier), but still we reuse keys between protocols.

regards,
Nikos

---

From: Fabrice Gautier <[email-masked]>
Date: Thu, 3 Dec 2015 10:40:47 -0800

> Schneier), but still we reuse keys between protocols.

Can we solve that problem generically by having TLS implementations
use different certs for different TLS version, and have an indicator
in the certs to indicate which version(s) they are for ?

-- Fabrice

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Dec 2015 22:47:52 +0200

> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier <[email-masked]> wrote:
> 

That’s a heavy-handed approach that requires servers to have multiple certificates and new selection logic.

Wouldn’t it be better to mandate that if your TLS implementation supports both TLS 1.2 and TLS 1.3 it should take actions necessary to mitigate the bleichenbacher attack?

In fact, if you don’t care much about very old browsers, isn’t it possible today to mandate that the TLS implementation not use RSA keying? That way the oracle is gone.

Seems better than requiring web server administrators to acquire two certificates.

Yoav

---

From: Dave Garrett <[email-masked]>
Date: Thu, 3 Dec 2015 17:31:07 -0500

> Seems better than requiring web server administrators to acquire two certificates.

A draft of the simple solution:
https://github.com/davegarrett/tls13-spec/commit/edeed6e90c177df6670935fceea69e14b3951e53

Dave

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Dec 2015 18:45:14 -0500

> implementation was lacking proper countermeasures not that long ago,

Can you describe the complete set of required countermeasures, and
prove they work comprehensively? What if the code is running on shared
hosting, where much better timing attacks are possible? What's
shocking is that this has been going on for well over a decade: the
right solution is to use robust key exchanges, and yet despite knowing
that this is possible, we've decided to throw patch onto patch on top
of a fundamentally broken idea. There is no fix for PKCS 1.5
encryption, just dirty hacks rooted in accidents of TLS.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Hanno Böck <[email-masked]>
Date: Fri, 4 Dec 2015 00:52:08 +0100

On Thu, 3 Dec 2015 18:45:14 -0500

> encryption, just dirty hacks rooted in accidents of TLS.

No disagreement here.

The thing is, we have a bunch of difficult options to choose from:

* Fully deprecate RSA key exchange.
The compatibility costs of this one are high. They are even higher
considering the fact that chrome wants to deprecate dhe and use rsa as
their fallback for hosts not doing ecdhe. ecdhe implementations weren't
widespred until quite recently. A lot of patent foo has e.g. stopped
some linux distros from shipping it.

* Separate keys for TLS 1.3 and TLS <= 1.2.
Complicated. Certificates are already too complicated for many people.
Do we really want to add more complexity by having different certs for
different TLS versions?

* Make sure proper countermeasures are implemented.
Also difficult. I just learned nss is not bleichenbacher-timing-safe.

Sounds like three bad options to me.

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

---

From: Fabrice Gautier <[email-masked]>
Date: Thu, 3 Dec 2015 17:11:39 -0800

> On Dec 3, 2015, at 12:47, Yoav Nir <[email-masked]> wrote:
> 
> 

Implementations already should have logic to select certificates based on SNI, so that doesn't seem so far fetched especially in the context of adopting TLS1.3.

> In fact, if you don’t care much about very old browsers, isn’t it possible today to mandate that the TLS implementation not use RSA keying? That way the oracle is gone.

Seems fine, for this specific attack, assuming you can ignore old clients and that your countermeasures are fully efficient.

On the other hand, having two keys seems like it would counter any current and future cross protocol attacks.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 4 Dec 2015 07:41:16 +0100

The use of the same RSA key for decryption and signature has always been 
problematic from a cryptographic point of view. As far as I am aware, all
current security theorems for TLS assume that the same RSA certificate (public key) 
is not used in both RSA and DHE ciphersuites. 

In theory this should be enforced by KeyUsage, there are distinct KeyUsages
for public key encryption and digital signatures and we may require that DHE/ECDHE
ciphersuites must use certificates that *do not* enable public key encryption,
and that clients must enforce this behavior.

Of course, the current practice is that KeyUsage is ignored. OpenSSL will
take a certificate that only specified Public Key Encryption and happily use
and accept it for digital signature. Similar flexibility allows ECDSA certs that
should only be used for signing to be used for static ECDH key exchange (leading
to other vulnerabilities). Do we (as in the TLS working group) have the necessary
influence to make sure that KeyUsage is respected?

> On 04 Dec 2015, at 02:11, Fabrice Gautier <[email-masked]> wrote:
> 
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 4 Dec 2015 07:01:19 +0000

> influence to make sure that KeyUsage is respected?

Suppose keyUsage is respected.  Who will knowingly shoot themselves
in the foot and restrict their RSA certificate to just DHE or just
RSA key transport?  This looks like an impractical counter-measure.

And by the way key usage is enforced by OpenSSL for EC.

    $ git grep -C3 X509v3_KU_ ssl
    ssl/ssl_lib.c-        X509_check_purpose(x, -1, 0);
    ssl/ssl_lib.c-# ifndef OPENSSL_NO_ECDH
    ssl/ssl_lib.c-        ecdh_ok = (x->ex_flags & EXFLAG_KUSAGE) ?
    ssl/ssl_lib.c:            (x->ex_kusage & X509v3_KU_KEY_AGREEMENT) : 1;
    ssl/ssl_lib.c-# endif
    ssl/ssl_lib.c-        ecdsa_ok = (x->ex_flags & EXFLAG_KUSAGE) ?
    ssl/ssl_lib.c:            (x->ex_kusage & X509v3_KU_DIGITAL_SIGNATURE) : 1;
    ssl/ssl_lib.c-        if (!(cpk->valid_flags & CERT_PKEY_SIGN))
    ssl/ssl_lib.c-            ecdsa_ok = 0;
    ssl/ssl_lib.c-        ecc_pkey = X509_get_pubkey(x);
    --
    ssl/ssl_lib.c-    }
    ssl/ssl_lib.c-    if (alg_k & SSL_kECDHe || alg_k & SSL_kECDHr) {
    ssl/ssl_lib.c-        /* key usage, if present, must allow key agreement */
    ssl/ssl_lib.c:        if (ku_reject(x, X509v3_KU_KEY_AGREEMENT)) {
    ssl/ssl_lib.c-            SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG,
    ssl/ssl_lib.c-                   SSL_R_ECC_CERT_NOT_FOR_KEY_AGREEMENT);
    ssl/ssl_lib.c-            return 0;
    --
    ssl/ssl_lib.c-    }
    ssl/ssl_lib.c-    if (alg_a & SSL_aECDSA) {
    ssl/ssl_lib.c-        /* key usage, if present, must allow signing */
    ssl/ssl_lib.c:        if (ku_reject(x, X509v3_KU_DIGITAL_SIGNATURE)) {
    ssl/ssl_lib.c-            SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG,
    ssl/ssl_lib.c-                   SSL_R_ECC_CERT_NOT_FOR_SIGNING);
    ssl/ssl_lib.c-            return 0;

-- 
	Viktor.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 4 Dec 2015 10:26:21 +0100

> RSA key transport?  This looks like an impractical counter-measure.

I guess we have to trade-off between different levels of “shooting oneself in the foot”.
For a company that has a bunch of certificates, one for each domain, separate ECDSA and RSA certificates etc.
spending a few more dollars on different certs for RSA encryption does not seem like a lot.

In any case, the main issue is whether we can get recipients to enforce key usage, not senders.
If a cert explicitly enables key exchange, encryption, and signature, it can be used for all of these.
However, if the cert restricts itself to digital signature, then the client should not use it for RSA encryption.
That way, the server gets to choose whether it wants protection from cross-protocol attacks or not,
and the client will enforce its wishes correctly.

Regarding ECDSA->ECDH cross-protocol attacks, the code that you pointed out in OpenSSL indeed
allows the server to ensure it does not use a sign-only cert for ECDH, but other libraries do not make this distinction.
Moreover, as far as I know, OpenSSL clients do not enforce this key usage restriction (See crypto/x509/x509type.c for the certificate usage rules.)
Neither, for that matter do other TLS clients like NSS etc. This allows attacks like the ECDH downgrade
in [1] and can probably make the ECDSA key recovery attack in [2] quite a bit worse.

From the viewpoint of provable security, I’d be suspicious of any TLS modes that allow the same
long-term keys to be used in multiple different ways. For RSA/EC, there are known attacks. But even otherwise,
their use requires a strong joint security assumption that we don’t really know how to justify.

-K.

[1] https://www.smacktls.com/smack.pdf <https://www.smacktls.com/smack.pdf>
[2] http://euklid.org/pdf/ECC_Invalid_Curve.pdf <http://euklid.org/pdf/ECC_Invalid_Curve.pdf>

---

From: Hubert Kario <[email-masked]>
Date: Fri, 04 Dec 2015 19:11:08 +0100

On Friday 04 December 2015 00:52:08 Hanno Böck wrote:
> > prove they work comprehensively? What if the code is running on
> > shared hosting, where much better timing attacks are possible?
> > What's shocking is that this has been going on for well over a
> > decade: the right solution is to use robust key exchanges, and yet
> > despite knowing that this is possible, we've decided to throw patch
> > onto patch on top of a fundamentally broken idea. There is no fix
> > for PKCS 1.5 encryption, just dirty hacks rooted in accidents of
> > TLS.
> 
> No disagreement here.
> 
> their fallback for hosts not doing ecdhe. ecdhe implementations
> weren't widespred until quite recently. A lot of patent foo has e.g.
> stopped some linux distros from shipping it.

Then maybe Chrome should reconsider.

I think we're overstating the compatibility costs.

very few widely deployed implementations (with the exception of the long 
deprecated Windows XP) lack support for DHE_RSA *and* ECDHE_RSA at the 
same time

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Fri, 04 Dec 2015 19:38:39 +0000

> Then maybe Chrome should reconsider.

Note that Apple has already removed DHE cipher suites from Safari in the
latest OS X and iOS releases, so advertising only DHE is already infeasible
for most servers.

I don't think telling servers to disable RSA ciphers and only advertise
DHE_RSA ciphers makes much sense. The set of servers which...

1. Are willing to disable plain RSA.
2. Don't have ECDHE support.
3. Are unwilling to take updates and get ECDHE support.
4. Support DHE support *with a sensible group*.
5. Are willing to deploy DHE with said sensible group despite the
compatibility and performance hit.

...is certainly all but nil.

David

> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Fabrice Gautier <[email-masked]>
Date: Fri, 4 Dec 2015 21:20:45 -0800

> On Dec 4, 2015, at 10:11, Hubert Kario <[email-masked]> wrote:
> 

The main issue with DHE_RSA is that there are still too many servers which will use short DHE group (<1024 bits). When connecting to those servers, using RSA is (presumably) safer.

From a compatibility aspect it's much simpler and safer to just disable DHE completely than to try to enforce a DHE limit, which would require a fallback connection to RSA.

-- Fabrice.