> On 3 Nov 2016, at 20:20, Martin Rex <m...@sap.com> wrote: > > Yoav Nir wrote: >> >> On 3 Nov 2016, at 16:31, Martin Rex <m...@sap.com> wrote: >>> >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>> which has existed through SSLv3->TLSv1.2 would be a problem. With the >>> removal of renegotiation from TLSv1.3, it is even less of a problem to >>> keep the contenttype in the clear. >> >> Here?s some to get this to somewhat >0: >> >> Most TLS 1.2 connections will have a few handshake records, >> followed by a couple of CCS records followed by a whole bunch of >> application records, followed possibly by a single Alert. >> >> You only see more handshake records in two cases: >> 1. The client decided to re-negotiate. That is exceedingly rare. >> 2. The server decided a renegotiation is needed >> so it sent a HelloRequest followed by a handshake. >> >> With visible content type, you can tell these two flows apart. > > (a) so what? for those interested, one can tell such flows appart > pretty reliably by traffic analysis. So there is exactly ZERO > protection against bad guys, while breaking the good guys.
There is if you pad the records to the size of application records. > (b) but TLSv1.2 remains unchanged, and this flow does not seem to > exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3. Re-negoatiation doesn’t, but post-handshake client authentication does: https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 <https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2> > -- so why would we need a backwards-incompatible change in a > protocol that protects something that no longer exists, > but which severely breaks existing middleware, making it > impossible to drop-in replace a TLSv1.2 implementation with > a TLSv1.3 implementation that has this backwards-incompatibility. Can you elaborate on that middleware? Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
