On Tue, Nov 26, 2024, 7:19 PM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> Watson Ladd <watsonbl...@gmail.com> writes: > > >The draft isn't a minor change: it makes handshake and record layer > changes > >so everyone would need to install new software and suffer similar compat > >issues as with a 1.3 update. > > This has already been answered several times both in the draft and > previously > in the discussion, but here it is again, re-posting one of the previous > replies: > The difference is that TLS 1.3 requires a complete new protocol stack > while > the draft is a minimal tweak to a few known problem areas in TLS 1.2 > while > being compatible with existing infrastructure built around 1.2 (or 1.0 in > some cases) - newer devices get 1.2TLS, existing ones stay on 1.2/1.0 > until > they get replaced. They're completely different things. > How is it more compatible with that infrastructure than 1.3 - it has to support EtM, unless you change to AEAD schemes - the handshake has a number of changes that need understanding by middle boxes that care This seems pretty similar to TLS 1.3 where middle boxes see TLS 1.2 resumption unless they try to be cleaver, but with the disadvantage that Google engineers are not buying every bit of problematic hardware to see what works around it. Do you have any deployment experience to back up your assertions it is more compatible? > Peter. >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
