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

[Phillip Hallam-Baker <[e-mail]>]

I have a slightly different perspective on this. To me, a Web Server is
just another type of middle-box.

Specifically, it is a middle-box between the content provider and the
content-consumer. And those are the ends I wish to achieve end-to-end
security between.

Transport security is useful but that has been our only hammer for 25 years
now. Data in transport is a solved problem, the breaches occur in data at
rest. And as a famous Snowden breach slide shows: 'TLS added and removed
here'.

This is not to say anyone made an error in design. What was possible when
we were looking at this in 1993 was considerably less than what we can do
today. We were using export grade encryption for a start. And we could
barely use one layer of encryption. And so we adopted TLS as a Golidlocks
solution that provided most of the network layer security we need and most
of the application layer security.

I think we need to change our perspective somewhat because we need TLS and
Data at rest security (DARS) and we do need certain types of metering. But
in the network, not in the inter-network.

Alice uploads content to Carol's Cloud, Bob reads it with his browser.
There are three (potentially) separate networks here.

Alice's local network
Bob's local network
Carol's local network

Alice, Bob and Carol might all see the need to do certain types of
monitoring. But the principle of least privilege should apply in each case.
Carol's need to monitor her network is strictly limited to Carol's needs.

In addition, we have the inter-network which as Einer Stefferud used to
remind us, isn't a network, it is a network of networks. And so the
communication graph is:

Alice <-> Internet <-> Carol <-> Internet <-> Bob

And that matters, because the primary concerns we are addressing in TLS are
the ones raised by that 'Internet' hop. The advantage of IPSEC over TLS is
that it allows us a much more closely targeted solution that locks down the
Internet hop without affecting anything else. The disadvantages of IPSEC...

So what I see happening at the moment is QUIC/TLS morphing into what IPSEC
was originally trying to do. Which is fine except that as EKR is point out,
this is compromising us at the upper layers. Which is where Shen and SHTTP
were originally intended to work.


I am actually planning to use three layers of encryption for Mesh services

Transport - (TLS) to provide traffic analysis resistance.
Presentation - (DARE) to authenticate client/server interactions
Data - To protect data at rest

The concern that Transport Layer Security inevitably creates is that any
scheme which provides any traction against traffic analysis is going to
make monitoring difficult because it is traffic analysis.

In summary, there is no way to square this circle because what
distinguishes traffic analysis attack from monitoring is intent and
machines can't tell the intent. And so if people want to expose information
at the lower layers, they are going to need to think about additional
layers of crypto being added at the top.