On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote: > 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).
MTI does not mean Mandatory To Enable > 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). yes, that's what I'm afraid of > 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. 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 -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
