Ilari Liusvaara wrote: > 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).
Nope, ZERO benefits. But it totally breaks the middleware _at_the_endpoints_! > > 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. Wrong. If one is using an architecture where the TLS protocol stack is transportless, so that the network communication can be performed efficiently (coalescing TLS records that are trickling in), then the *REAL* content type is quite important for knowing whether the TLS handshake is still ongoing, or whether it is already complete. The way I've built this is that the middleware has a timeout for the TLS handshake in its entirety (independent of the number of roundtrips), and at the same time promises the application a network readable event for every incoming TLS record with application data. This only works if I can leave TLS appdata records partially in the incoming network buffer, and for this I must be able to recognize them. For processing TLS records with Handshake messages, pre-reading and passing multiple of them is preferable and much more efficient (if TLS handshake messages come in seperate TLS records each, which some implementations do). Pre-reading TLS records with handshake messages, but not prereading TLS records with AppData (so that network readable events will remain visible for app data) is only possible if I see the contents on the outside of the record by just reading the TLS record header. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
