Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

[Peter Gutmann <[e-mail]>]

Tom Herbert <[e-mail]> writes:

>The problems of protocol ossification and middleboxes meddling in E2E
>protocols has been discussed at length in IETF in various contexts.

I'm aware of RFC 3234, which was written seventeen years ago and focuses on
middleboxes messing with application-layer data, as well as farcical stuff
like RFC 3424, of the same vintage, but it's mostly complaining rather than
actual rigorous analysis, and often seems to be based on opposition to
middleboxes as an article of faith, notoriously manifested in IPsec's "NAT is
bad, therefore we will make sure IPsec breaks NAT, because NAT is bad", which
has caused endless headaches for pretty much anyone who's ever had to work
with IPsec ever since.

In particular for this case, since the discussion is about header encryption
and not middleboxes in general, I'm not aware of any rigorous analysis of its
purported benefits, or even a clear statement of its purported benefits,
something like "here is a definition of the service that header encryption
provides, here is a real-world study showing that it provides this and
demonstrating that it can't be readily defeated".  Contrast this with the two
dozen plus studies that look at the analysis of encrypted traffic despite the
encryption, an example being (just one picked at random) "Identifying HTTPS-
Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch,
Proceedings of the 7th Conference on Data and Application Security and Privacy
(CODASPY'17), March 2017, p.361.

So when people complain that the draft doesn't say enough about all the Good
Things header encryption provides, I would respond that it does, it's cited
all of the available literature on the benefits of header encryption, and all
of the studies showing that it's effective, in Appendix B.

The draft is actually quite restrained in this regard, as I mentioned in my
previous message the two notable examples of header encryption/protection
deployed at scale into the real world, IPsec and SSH, have both been a
disaster (for functionality, IPsec, and security, SSH), but it very politely
omits mention of this.

Peter.