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

[Ilari Liusvaara <[e-mail]>]

On Fri, Oct 28, 2016 at 08:35:45PM +0200, Martin Rex wrote:
> 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_!

Allowing padding is already a large benefit. TLS 1.2 AEAD modes don't
allow padding, causing rather large unavoidable information leaks.
Especially with HTTP/1.1, which doesn't have application-level padding
mechanism nor multiplexing.


Also, things like this should have been discussed like year or two
ago. Right now it is too late for major changes like this without good
cryptographic justifications (which AFAICT don't exist).

> > 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.
> 
> 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.

I implemented zero-copy (for TLS decoding) packet receving in TLS
lib I am writing. Works in both TLS 1.2 and 1.3.

Rather big efficiency boost too... I suspect doing the same for
encoding would be another big efficiency boost.

> 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.

Note that even if the record is truly appdata, it may not contain
any data, and one can't tell this from just the type.

> 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.

Also, TLS 1.3, it isn't safe to reorder appdata records across
handshake records, which can be sent after primary handshake
has completed.


-Ilari