On Fri, Oct 28, 2016 at 06:00:03PM +0200, Martin Rex wrote: > Joseph Salowey wrote: > > There are two seriously backwards-incompatible changes in the > current proposal that provide zero value, but completely break > backwards-compatibility with existing middleware infrastructure. > > > (1) hiding of the TLS record content types. > Please leave the TLS record types (handshake/AppData/Alert/CCS) > clearly visible on the outside of the TLS records, so that > middleware protocol parsers (which interface to transport-free > TLS protocol stacks) can continue to work, and continue to > work efficiently.
Hiding the types does have its benefits (and it is also used for zero-overhead padding scheme). And also, TLS 1.3 handshake is so darn different from TLS 1.2, that you couldn't do anything sane even if you had record types. > (2) hiding of the TLS extension SNI. > Right now it is perferctly fine to implement TLS extensions SNI > on the server completely outside the TLS protocol stack to route > to single-cert SNI-unaware backends. The current proposal > suggest to move TLS extension SNI into the encrypted part, if > my superficial reading of the draft is correct, so TLSv1.3 > will not fly with existing architectures where spreading of > TLS requests on the server-side based on TLS extension SNI > is done outside of the TLS protocol stack (i.e. bottleneck-less > without having to open TLS). Who actually cares about server-side SNI? And it wasn't like you could do anything useful with server-side SNI in TLS 1.2 either. You can still route connections on SNI, and it even works the same way it did in TLS 1.2 (so existing code works). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
