Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[[e-mail] (Martin Rex)]

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