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

On Nov 9, 2016 9:43 AM, "Martin Rex" <mrex@sap.com> wrote:
>
> Daniel Kahn Gillmor wrote:
> >
> > Martin Rex wrote:
> >>
> >> The problem here is that this breaks (network) flow control, existing
> >> (network socket) event management, and direction-independent connection
> >> closure, and does so completely without value.
> >
> > Martin, you keep saying things like "without value", while other people
> > on this thread (Rich, Ilari, Yoav) have given you examples of the value
> > it provides.  You don't seem to be trying to understand those positions.
>
> Nobody so far has provide a single example of *REAL* value.
> For the hiding of ContentType to provide real value, the prerequisites
are:
>
>   (1) this value will be _unconditionally_ provided in TLSv1.3
>
>   (2) this value can be demonstrated to be a real security issue in
TLSv1.2,
>       for existing usage scenarios, where hiding of ContentType is not
>       available
>
> Anyhing less is no value, just an illusion of value.
>
>
> >
> > This WG isn't chartered to defend the engineering optimizations made by
> > any particular middlebox vendor.  It's chartered to improve the privacy
> > and security guarantees offered to users of TLS.
>
> You are confusing _middlebox_ with _middleware_at_the_endpoint_,
> which is a huge difference, because the middleboxes are performing
> man-in-the-middle attacks, whereas the _middleware_at_the_endpoint_
> has regular access to the entire plaintext of the communication.
>
> The problem with hiding of TLS record ContentTypes is that it severely
> interferes with efficient streaming network I/O--which is preferably
> performed outside/above the TLS implementation and async non-blocking
> whenever you get into thousands of parallel connections.

No one else has reported this. That's including Microsoft whose
implementation does hand over all IO to the application. Absent many more
details you are not convincing me there is a problem.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls