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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
