On Wed 2016-11-09 03:31:22 -0600, 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.
Your description of the problems it causes you are difficult to follow,
and it doesn't sound like they have been experienced by other
implementors. But other people are actively trying to make sure they
understand your concerns (like ekr's post downthread here).
Could you offer the rest of the list the same courtesy?
Your earlier argument that the hidden data is deducable by traffic
analysis anyway isn't a satisfying argument, for two reasons:
(a) if it were reliably true, then your implementations could simply
adopt the traffic analysis approach instead of inspecting the
cleartext content types. If it causes too much additional expense,
then it should increase the expense for adversaries who are
monitoring traffic for these same signals as well, which is a
security+privacy win.
(b) We're including mechanisms (like padding) to make traffic analysis
harder. More research is needed to know how to best provide this
sort of indistinguishability. But if we decide instead that it's ok
to directly publish any data that could possibly be inferred by
traffic analysis, we will never improve the security of TLS for its
users against traffic analysis, which will only grow more
sophisticated over time. Why should we accept this limitation on
TLS?
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.
Regards,
--dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
