Subject: [tsvwg] Fwd: New revision 11 after WGLC - draft-ietf-tsvwg-transport-encrypt

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 31 Jan 2020 18:48:49 +0000

We've just uploaded a new revision of this document. We hope think this 
addresses the issues raised by Martin's review.

The htmlized version of this revised draft is available at:

https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-11

To help explain the changes in the new draft we include our track through your comments with responses,labelled [GF].

Gorry & Colin

---- Review comments from Martin:

Lots of changes here.  It took me a while to get through this. The 
tweaks to the conclusion make it a lot better.  I'm still concerned 
about the tone of the middle sections though.  Though there isn't 
anything direct, there is a strong theme throughout that suggests a 
particular viewpoint has greater validity than another.

For instance, compare this text:

    A network operator supporting traffic that uses transport header
    encryption is unable to use tools that rely on transport protocol
    information.  However, the use of encryption has the desirable effect
    of preventing unintended observation of the payload data and these
    tools seldom seek to observe the payload, or other application
    details.  A flow that hides its transport header information could
    imply "don't touch" to some operators.  This might limit a trouble-
    shooting response to "can't help, no trouble found".

With the use of scare quotes here:

    o  One motive to encrypt transport headers is in response to
       perceptions that the network has become ossified, since traffic
       inspecting middleboxes prevent new protocols and mechanisms from
       being deployed.  This has lead to a perception that there is too
       much "manipulation" of protocol headers within the network, and
       that designing to deploy in such networks is preventing transport
       evolution.  One benefit of encrypting transport headers is that it
       can help improve the pace of transport development by eliminating
       interference by deployed middleboxes.

So, while I think that this is greatly improved, I don't think that it's 
careful enough.
[GF] DONE. I suspect you're reading-in much more than intended. The 
middle sentence here has now been removed to seek to avoid this. And 
we've done some similar adjustments elseewhere.

Some more detailed stuff follows:

The last sentence of the abstract seems to juxtapose protecting user 
privacy with these other properties, but ossification protection is 
generally classified alongside encryption for privacy.  Maybe the right 
way to approach this is to recognize that these are all design 
considerations without attributing any particular weight to anything in 
particular.
[GF] DONE. Fine, now just a list.

The introduction seems to be a complete rewrite.
[GF] That was what we were asked to do.

This is probably just me, but I found the treatment of encryption vs. 
authentication to be better in the old version.  The current setup says 
a lot about encryption and occasionally mentions authentication, but it 
doesn't really address the three states as well as before:

* network can do nothing with the field/property
* network can read but not modify the field/property
* network read and modify the field/property

[GF] We have added back some of what we formally removed. It’s a little 
hard to know how much will satisfy everyone…

That's been a very important classification for us in QUIC and one that 
I think could be clearer up front.

I think that the "middle ground" paragraph in the intro might benefit 
from citing RFC 8558.  Namely, recognizing that the choice of what to 
encrypt and what to protect is a deliberate choice for each field.
[GF] DONE. RFC8558 is an IAB RFC, I see no issues in including as reference.

In Section 2, the inferences about motivations behind QUIC's choices 
aren't entirely accurate or complete.  Part of those are (again) more 
fully articulated in RFC 8558.  Specifically missing here: use of 
encryption is motivated by a desire to ensure that signals to the path 
are deliberate.  And that signals are disjoint from endpoint state so 
that they don't leak information that might reveal private information.  
To give a concrete example, encrypting packet numbers is motivated by a 
design to avoid linkability.  While we might not mind on-path elements 
being able to read order and gaps, when a session traverses different 
paths, exposing the information is a liability.  That this might also 
help when it comes to deploying traffic analysis resistance was also 
considered (that is, traffic analysis in the sense of using transport 
signals to infer things about payload plaintext).
We will add something.

Widespread use of transport header encryption could limit such 
observations in future.
It might be more accurate to say that "Transport header encryption 
intentionally limits the information available to network observers."
[GF] DONE. I don't actually agree that the design had always been 
motivated by this intention to limit... However, it never the less does 
limit , and I reworked to use the words you have written.

Section 2.1 talks about observation, but modification is discussed here 
also and it probably needs better recognition.  (BTW, the brief sampling 
of the ways in which ossification occurs here is still fantastic.)
[GF] DONE. Understood - this modification text was introduced because of 
an expressed wish to include examples from MPTCP. You’re correct and we 
updated slightly - but would like to avoid digging too deep. We will 
also provide more benign examples such as ROHC and the TCP ACK reduction 
methods that fail to work when protocols change or new protocols emerge.

I would also s/hard-coded/hard-coded or incomplete/ to recognize that 
these are compliant, but because they don't terminate TCP they need 
their understanding to be complete before they interfere.
[GF] DONE. Added incomplete.

The last paragraph in 2.1 might benefit from citing RFC 8546, 
specifically with reference to what *isn't* encrypted.
Because you are talking about what leaks around the edges.  This is 
saying "what isn't encrypted can ossify; you can't encrypt everything; 
and the use of heuristics or machine learning based on any unprotected 
signals can ossify too", but it could be clearer.
[GF] DONE. Fine, added ref to RFC8546.

Section 2.2 makes a subtly different recommendation to RFC 8558 that I 
don't know is as good.  RFC 8558 says "Signals exposed to the path 
should be decoupled from signals that drive the protocol state machines 
in endpoints."  I think that the suggested approach here is broadly 
right, but I would prefer that this is just offering a more complete 
interpretation of that recommendation. More so because the cited Section 
4 doesn't really include any suggestion that would be consistent with 8558.
[GF] I’m familiar with that, and you may think so, we could explicitly 
say there is a subtle difference, if this helps. Although I am not sure 
it is useful to drill there. My recollection of the debate in the 
SPUD/PLUS BOF was unpleasant and didn't result in technical completeness 
- and really  I'd really prefer not to choose to dig deeply here into 
cases were exposing signals linked to a protocol state machine are a 
desirable outcome - and when they are undesirable. I suspect functions 
relating to higher layers (e.g. flow control) can be more abstract; but 
ones like to packet loss metrics have value in knowing the transport is 
acting on the same information. I think the new text is better.
[GF] Done. Added text noting RFC 8558 saying there may be merit in 
Signals exposed to the path that are decoupled from signals that drive 
the protocol state machines in endpoints. 
Section 2.3 contains a little bit of speculation that probably doesn't 
belong in this sort of document.  Specifically "Operators might work 
without that  ..."  I might not have mentioned that before, but it's 
more obvious now.  That sort of statement strongly implies judgment as 
well.  Not saying that we shouldn't be judgmental when we can agree on 
the conclusion, but I would rather be direct or say nothing at all.  In 
this case, as this is a point of contention, saying nothing seems the 
only reasonable course of action.
[GF] I don’t think there’s not much speculation here. It’s written as 
though this might be the case, that may be the case, but it’s certain 
that if the information is obscured you can either live without it; or 
you can seek new ways to get it. People are taking both approaches. 
Choices vary, often because of a range of operational conditions, and 
not all operators have the same concerns, issues, etc.  This is a 
sentence that was discussed. We’ll try rephrasing:

Also in Section 2.3, "Traffic Analysis" is a term of art that might be 
confusing given how close this section is to the meaning I understand it 
to have (use of information leaks from size and timing to infer things 
about content of communications).  I might suggest that you use Analysis 
of Aggregate Traffic or something like that.
[GF] Done. If you feel some people nuance the term “traffic analysis", I 
would be fine with your proposal.

Overall, Section 2.3 still gives the impression that it is making a 
judgment where it could just stop at describing the practice. It would 
be much shorter as a result.  (The effect of repetition here is such 
that even if the judge-y bits were kept, they could be factored into a 
single statement.)
[GF] This section came from a variety of places, it’s based on what is 
and has been done, practices vary, those that are more focussed on one 
are often less focussed on another. It is not necessary to judge them in 
this document - I think it is really helpful to understand the expressed 
concerns. So for the moment I have retained them. I suggest we change 
the section title to “2.3.  Perspectives on Observable Transport Header 
Fields”.

The final paragraph of Section 3.1.1 reiterates some speculation about 
how traffic analysis (in the sense I understand it) could be used to 
extract necessary information.  The example given is a good one, because 
I have first-hand knowledge of that specific type of traffic analysis 
being deployed.  However, the effect of the statement is to imply "don't 
both encrypting this, because it can be inferred via traffic analysis".  
I know that this is a widely-held view, but I don't think that it has 
consensus.  If the IETF wants to make that statement, then it should be 
direct.  The statement to make here is the one made in RFC 8546.  
Anything more than that needs to be very careful.

My take here is there is plenty of prior-art both within IETF specs and 
operations, and whilst we can cite the IAB guidance this should not stop 
the IETF transport area from reflecting on this topic.
[GF] DONE Added text around RFC 8546 providing a summary by the IAB of 
implications that increased encryption has for network functions that 
use the wire image and then describes the expected benefits of 
explicitly declaring protocol invariants that can be used for this purpose. 
In Section 3.1.2, why is the sequence number needed to infer rate and 
volume?  The added note about flow identification seems to be all that 
is needed, and even that point might be debated on the basis that source 
and destination pairs are sufficient.
[GF] Done.  We modified the text to state volume first, and added 
examples around how sequence numbers could be used (e.g., measurements 
observing counters in periodic reports such as RTCP; or measurements 
observing protocol sequence numbers in statistical samples of packet 
flows or specific control packets, such as those observed at the start 
and end of a flow).

Nits:

The last paragraph of Section 3.1.2 might be missing a "to".

[GF] Thanks, done.

Check your use of section references.  I see lowercase s
[GF] Fixed.
and a "Section Section 5".
[GF] Found and fixed, thanks.
https://www.quickanddirtytips.com/sites/default/files/styles/insert_large/public/images/937/use-utilize-pin.png?itok=Bt7A6RQq
[GF] Text updated.