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

[Christian Huitema <[e-mail]>]

On 11/4/2019 6:59 AM, Mirja Kuehlewind wrote:
> ...
>
> Well, we put a single, optional, bit in the header and everything else
> we could figure out how to encrypt encrypted. It's true that
> encryption has a cost to the design of the protocol and to the
> endpoint implementations and we've been trying to balance that cost
> against the value, but that's not because the group isn't trying to
> encrypt as much as possible.
>
>  
>
> [MK]I don’t think we need to nit-pick here but I think "encrypt all
> the things" and “encrypt as much as possible” is not the same,
> especially as “possible” is something to argue about when it comes to
> the question of how much you are willing to pay. However, I don’t
> think we need to discuss this in details here, just wanted to say that
> I don’t think the situation is a simple as you have stated and I don’t
> think there is consensus for a simple "encrypt all the things".
>
>  
>
> I certainly realize that there are people who are sad about this -- as
> you rightly point out reflected in this draft –
>
>  
>
> [MK] I don’t think people are sad about increasing amount of
> encryption. But when we change things we also need to have a
> discussion of the implication of this change and cannot just close our
> eyes. As I said in some cases we might be happy about things that
> hopefully just go away, in other cases it may actually have more
> severe impact of the viability of the Internet as a interconnected
> network that is operated by different entities.
>
>  
>
> but I believe they are in the rough, at least of the community of
> people actively designing and deploying new protocols.
>
>  
>
> [MK] I don’t believe this. Otherwise I wondering why we had such a
> lengthy discussion for more than a year in the QUIC working group.
>
We had that discussion, and there were indeed two opposing ideas: on one
hand, expose some information to the path for network management
purpose; on the other hand avoid exposing information to prevent
ossification and interference, and to avoid privacy issues. Only some
the "network management" arguments actually gained some traction:
enabling measurements of network latency, enabling measurement of data
rates, and enabling measurement of packet losses. One of the problem
with the current draft is that it does not distinguish between these
"common ground" objectives and a slew of other "network management"
practices, such as discriminating between flows or interfering with
transport protocols. It also mixes in transport protocol debugging,
which is a different subject.

Just because we have some consensus on the legitimacy of measuring
latency, data rates and packet losses does not mean that we want to
incorporate support in the transport protocol. We quickly realize that
there is nothing particular needed for measuring data rates, beside
separating flows by five tuples and counting packets. We struggled with
the privacy implications of measuring latency, because doing so may
enable triangulation and does enable the detection of proxies. We also
failed to achieve consensus on a specific way to enable packet loss
measurement, because we could not reach consensus on a specific algorithm.

The QUIC working group converged on enabling latency measurements on a
fraction of the flow. It appears that measuring a relatively small
fraction of the flows is sufficient to gather statistically significant
measurements of latency. Ensuring that a sufficient fraction of the
flows is not measurable enables privacy protection for sensitive flows
that need to hide usage of proxies.

The draft does not include this kind of discussions.

>  
>
> Do you see any plausible situation in which a new transport protocol
> isn't largely encrypted?
>
>  
>
> [MK] That’s not the intention here. But we also need to consider ways
> to interact with the network where this brings benefit to both the
> network and the performance of the end-to-end traffic. There are
> situation where this is the case. And I don’t think one makes sense
> without the other.
>

You seem to be arguing for something like "performance enhancing
proxies". End-to-end encryption is indeed a way to opt out of such
proxying. Measurements so far indicate that opting out has very little
impact on actual performance, and that whatever impact there is could be
reduced by improvements in end-to-end algorithms. In fact, in many
cases, end to end performance is better without such proxies. But the
real reason for the opposition to the concept is ossification. Enabling
such proxies would quickly ossify the new transports, and a such there
is a strong consensus in the end-to-end transport designers to use
encryption and prevent interference by such devices.

This does not mean that network level deployment have no role in the
future. I could see for example tunnels deployed that use FEC or local
retransmission to mask the poor performance of a particular subnet. Or I
could see end-to-end devices opting into some kinds of application level
caching services in order to improve performance. But the draft should
be clear: transport protocols do not have to enable interference with
the transport bits.

My take is that this draft should not be published as is. It should be
rewritten to actually reflect the consensus of the transport area, which
has to reflect in particular the work in the QUIC working group.

-- Christian Huitema