Subject: [TLS] No cypher overlap (was: ban more old crap)

From: Hubert Kario <[email-masked]>
Date: Tue, 28 Jul 2015 17:41:58 +0200

I see one possible problem with TLS1.3 not being a superset of TLS1.2.

Consider the following:
  Server which supports TLSv1.3 but is configured to accept only AES256 
ciphers.
  Client which advertises TLSv1.3, but no support for AES256-GCM. The client 
advertises also CBC ciphers (both AES128 and AES256) as it wants to be able
to connect to legacy servers too.

Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or 
should it be aborted?

I think we should go for continue connection with downgraded protocol, but 
explicitly say that it may not happen if the negotiated ciphersuite would be 
DES, RC4, export grade...

That would allow us to reiterate in the TLS1.3 spec that they are a big no-no, 
and that if you claim support for TLS1.3 you should never negotiate them with 
a similarly modern peer.
-- 
Regards,
Hubert Kario
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: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 16:01:55 +0000

> Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or 

We already see a similar dilemma with clients that (artificially)
support only SSLv2 ciphersuites, but advertise TLS protocol versions.
OpenSSL will first choose a common protocol (TLS 1.x) and then fail
to find any shared ciphers.  To complete the connection, the client
must explicitly request only SSL 2.0.  There is at present no
filtering out of protocol choices for lack of compatible ciphers.

> DES, RC4, export grade...

In that case, it should be said that a client MUST NOT advertise
TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers
(or perhaps less restrictive at least one TLS 1.3 compatible cipher).

Otherwise, there'll be lots of clients whose TLS libraries advertise
1.3 (just because they implement the protocol), but whose cipher
configuration includes only TLS 1.2 (or lower) suites (because the
application configuration has not been updated).

Punishing those clients by having servers abort the handshake is
a bad idea.  The right outcome is use of TLS 1.2, whether because
client implementations of 1.3 need to check that adequate cipher
suites are available, or because servers negotiate 1.2 when 1.3
is impossible.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 29 Jul 2015 11:59:41 +0200

On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote:
> > explicitly say that it may not happen if the negotiated ciphersuite would
> > be DES, RC4, export grade...
> 

MTI does not mean Mandatory To Enable

> application configuration has not been updated).

yes, that's what I'm afraid of

> suites are available, or because servers negotiate 1.2 when 1.3

neither clients nor servers are required to support (have them enabled) all 
ciphersuites defined for TLS1.3, so there is always chance for no common 
cipher between them