On Thu, Nov 03, 2016 at 08:38:32PM +0200, Yoav Nir wrote: > > > On 3 Nov 2016, at 20:20, Martin Rex <[email protected]> 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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
