[tsvwg] Fwd: New revision 11 after WGLC - draft-ietf-tsvwg-transport-encrypt
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 31 January 2020 18:48 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7BF120815 for <tsvwg@ietfa.amsl.com>; Fri, 31 Jan 2020 10:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUA3MnshI4f4 for <tsvwg@ietfa.amsl.com>; Fri, 31 Jan 2020 10:48:53 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 10FB6120105 for <tsvwg@ietf.org>; Fri, 31 Jan 2020 10:48:53 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9444E1B001AB; Fri, 31 Jan 2020 18:48:49 +0000 (GMT)
References: <2ce875ab-6a03-0650-0729-4e5fb0b75092@erg.abdn.ac.uk>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Forwarded-Message-Id: <2ce875ab-6a03-0650-0729-4e5fb0b75092@erg.abdn.ac.uk>
Message-ID: <24f8cdd0-395f-c4d4-29fa-7f914fda9aa0@erg.abdn.ac.uk>
Date: Fri, 31 Jan 2020 18:48:49 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <2ce875ab-6a03-0650-0729-4e5fb0b75092@erg.abdn.ac.uk>
Content-Type: multipart/alternative; boundary="------------C33A56D51FFAA262349A31D0"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/37rfs35a_Xe0CngLRXccU64z400>
Subject: [tsvwg] Fwd: New revision 11 after WGLC - draft-ietf-tsvwg-transport-encrypt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2020 18:48:56 -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.
- [tsvwg] Fwd: New revision 11 after WGLC - draft-i… Gorry Fairhurst