On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote:
> 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?
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.
> 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...
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
