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

[Ilari Liusvaara <[e-mail]>]

On Thu, Nov 03, 2016 at 08:38:32PM +0200, Yoav Nir wrote:
> 
> > On 3 Nov 2016, at 20:20, Martin Rex <[e-mail]> wrote:
> > 
> >     -- so why would we need a backwards-incompatible change in a
> >     protocol that protects something that no longer exists,
> >     but which severely breaks existing middleware, making it
> >     impossible to drop-in replace a TLSv1.2 implementation with
> >     a TLSv1.3 implementation that has this backwards-incompatibility.
> 
> Can you elaborate on that middleware?

Also, what platform (Java? .NET? Linux?) does that middleware run on,
and some base interfaces from standard library (or widespread
extensions) it uses for its API...


What I think I gathered from the description (and this sounds very
bizarre):

- Upon new data indication, the middleware peeks TLS header from the
  incoming data buffer.
- If it is not appdata, it is read and handled.
- If it appdata, the socket readable indication is passed to the
  application (what supports that without wrapping the socket???)
  which it then reads (and presumably passes for decryption).


That sounds much more bizarre than the zerocopy APIs in btls (the
TLS lib I am working on), and those are already pretty odd.


-Ilari