On Thursday, 24 May 2018 18:51:08 CEST Viktor Dukhovni wrote: > > On May 24, 2018, at 12:30 PM, Adam Langley <a...@imperialviolet.org> wrote: > > > > I think quite a lot of clients are going to be advertising compression > > using this code point in the coming months. They should only do so when > > offering TLS 1.3, which presumably LTS clients would not, so maybe there's > > something you could use there. > > It might still be prudent to get the new code point re-assigned. I > can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS > preferred when using TLS 1.2.
I personally would prefer a different approach to TLS-LTS than what was proposed then, so what uses ext 26 now may very well not be compatible with the RFC'd version... don't know how much of a problem would it be to implementations that Peter shipped and yes, IMNSHO the TLS-LTS makes sense only in case the modern stacks (i.e. ones that support TLS 1.3) also support it and prefer it over vanilla TLS 1.2 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 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
