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

[Tom Herbert <[e-mail]>]

On Wed, Nov 6, 2019 at 10:51 PM Peter Gutmann <[e-mail]> wrote:
>
> Stephen Farrell <[e-mail]> writes:
>
> >In addition, the document is missing any real description of the harmful ways
> >in which cleartext headers are being (ab)used today.
>
> That's actually something that's missing in general, not specifically in this
> document.  Header encryption seems to be taken as an article of faith, we must
> do this because it's something we must do, and yet from long experience with
> the two protocols that do header encryption (or at least protection), IPsec
> and SSH, for the former all it's produced is endless and ongoing headaches for
> devices that need to forward/route/manage IPsec traffic, and for the latter
> all it's produced is a string of security vulnerabilities.
>
> So what's the sound technical - not religious - argument for header
> encryption?  Calling it "abuse" is a purely subjective statement, one person's
> abuse is another's essential functionality.  One big example of this DNS
> manipulation to implement captive portals, which the DNSSEC folks I've talked
> to regard as anathema but without which maybe 90% [figure totally invented] of
> public WiFi won't work.  So to the DNSSEC fans it's abuse, to pretty much
> everyone else except a few DNSSEC fans it's fine because they want public WiFi
> to work for them.
>
> In particular for header encryption there have been at least two dozen papers
> published, and many commercial products created, that bypass encryption to do
> fairly extensive traffic analysis *of encrypted traffic*, encrypted headers or
> no.  So on the one hand we've got real-world experience with two protocols
> that do header encryption/protection which has yielded endless problems
> (IPsec) and security vulns (SSH), and on the other hand we've got what seems
> to be a faith-based belief in something that numerous academic papers have
> shown doesn't provide the service it claims to.
>
Peter,

The problems of protocol ossification and middleboxes meddling in E2E
protocols has been discussed at length in IETF in various contexts.
This is a real problem. It is well known that encryption of as much as
the packet as possible is one mitigation to present protocol
ossification. For instance, this was exactly the rationale in QUIC to
encrypt the whole transport layer.

On the other hand, the draft provides most anecdotal information that
plaintext headers are useful. For instance, there's a lot of
discussion about network operations. It is conceivable that this
unencrypted headers might help network operators, but then that raises
some obvious questions. Do all operators look into transport layer? Do
all network operator require the same information from the transport
layer header? If they do, what is the EXACT set of transport layer
information they need? Do they all support the same transport layer
protocols? What if we start using a new transport layer protocol from
hosts, are we out of luck because that protocol is not on the
"approved list"?

If there were answers to such questions then real requirements both on
the host side and network side could be articulated and there might be
a basis for a meaningful discussion, but in lieu of that all we are
left with is vague guidance for the transport layer protocol designer
that they should consider how middleboxes _might_ to meddle in the
protocol.

Tom

> Where's the technical argument for header encryption, backed by actual
> research showing that it's effective, and that the benefits outweigh the
> disadvantages?
>
> Peter.
>