[tsvwg] Suggestions on draft-ietf-tsvwg-transport-encrypt-09

Tommy Pauly <tpauly@apple.com> Thu, 07 November 2019 17:08 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7189D120990 for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 09:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CeTnCR69YU0K for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 09:08:31 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27E112094C for <tsvwg@ietf.org>; Thu, 7 Nov 2019 09:08:30 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com []) by ma1-aaemail-dr-lapp03.apple.com ( with SMTP id xA7H81eK036854 for <tsvwg@ietf.org>; Thu, 7 Nov 2019 09:08:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=rG+GJJw0IYhuByxUMvcOiyavEA9kqP+Yv4Xpky86K8g=; b=VcmMUTV48S4bDDAHfAlVHAJGyC6mKQdiglgGwe+UUJijn6w4tjouhg5Mzp8UOPy4/NDO sgprSYkCSm8GQazVVuR+NaJ+IY+DIxKECZRJY8Jm5Y8HKMy/qk3NY3LZmOQq6bUD4FbH ZTnM1NXa36GImX+J+wkDpvlzwMJkhjkU5Dya0k3AXofDjUPae8EpLwZ6UjqyoceoljnV bnNGyMiZlfxOY0shfiuBr9fHNjfkr+vBQj6XVO0qQ5gELhhGSZ2LKs5jSfjHUSfpYZXh EC/8/9KiHAYCeUHLms8hYPkyJYSQdtodAABQATXiAx7ZtkNfxZ2Ryix32KGVM8jaLHir UQ==
Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com []) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2w41v4a4sm-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <tsvwg@ietf.org>; Thu, 07 Nov 2019 09:08:29 -0800
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com []) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <0Q0L006X8ZM4NE30@mr2-mtap-s01.rno.apple.com> for tsvwg@ietf.org; Thu, 07 Nov 2019 09:08:28 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <0Q0L00I00YVIAY00@nwk-mmpp-sz10.apple.com> for tsvwg@ietf.org; Thu, 07 Nov 2019 09:08:28 -0800 (PST)
X-Va-T-CD: 841195a7c29ae2f27236503a97bc7080
X-Va-E-CD: 8f50d9006823beea622f99990004ac04
X-Va-R-CD: f24ff66e5a1036f05db9b5cb41d8166d
X-Va-CD: 0
X-Va-ID: 4810ed3b-e726-4747-9658-e73ed683d917
X-V-T-CD: 841195a7c29ae2f27236503a97bc7080
X-V-E-CD: 8f50d9006823beea622f99990004ac04
X-V-R-CD: f24ff66e5a1036f05db9b5cb41d8166d
X-V-CD: 0
X-V-ID: 20d891dc-cc8f-4996-a295-2b18b0e3238a
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-07_05:,, signatures=0
Received: from [] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <0Q0L00F0KZM36740@nwk-mmpp-sz10.apple.com> for tsvwg@ietf.org; Thu, 07 Nov 2019 09:08:27 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Message-id: <DA05ACC7-2D5C-476B-97F3-EE95461ACB61@apple.com>
Date: Thu, 07 Nov 2019 09:08:25 -0800
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-07_05:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jTcQd0zIoV6m27WeT2CSErWE3qc>
Subject: [tsvwg] Suggestions on draft-ietf-tsvwg-transport-encrypt-09
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: Thu, 07 Nov 2019 17:08:36 -0000

Hello TSVWG,

I've just read through the latest update to the Transport Header Encryption Considerations draft, draft-ietf-tsvwg-transport-encrypt-09. First off, the changes to the introduction, etc, do make things clearer. Thanks to the authors for those changes!

In light of the discussion going back and forth on the intent and appropriateness of the draft, I do indeed agree with the points being raised that the tone of the draft is a bit inconsistent: reading through the introduction, I get the impression that this document will explain to the reader the new way things will work in the world of encrypting our transports. And indeed, section 2.1 does give some good transport-layer rationale about ossification. However, much of the rest of the document can indeed be read as pointing out a laundry list of problems (particularly section 6) with using encryption. I do not believe that the intent of this document is to discourage encryption (and I would have concerns if it were), but I can also understand how some readers can get that impression.

However, I do believe that a document in this space—a statement on and guide for transport protocols that are encrypted—is valuable. I think that the document does need to be edited to perform this role, but it can serve a positive role in clarifying the benefits and necessity of encryption.

Protocols like QUIC that provide transport header encryption are indeed a huge benefit to the development of transport protocols, since they allow us to keep doing work on changing the transport without being caught up by the ossification of the network. Not only is encryption of headers important for privacy and security, but it has become a necessary method to allow work on transport protocols to evolve. If this message can be carried throughout the document, I think the message will be clearer. Yes, the passive signals that previously allowed middleboxes to infer loss patterns will not be visible—but those same signals are the ones that prevent the transport from changing to improve (and also allows anyone else to fingerprint the user!). If the justification for having network signaling is that it is useful to allow the network to optimize and improve traffic performance and reliability, then the advocates for these optimizations should also take into account the fact that protocols that encrypt headers (like QUIC) are the places where we can successfully deploy performance enhancements like 0-RTT connection setup and connection migration, in ways that cleartext solutions like TFO and MPTCP stumble.

As has been pointed out already, much of the operational considerations are already described by RFC 8404. Some of the discussion of these operational considerations in the TSV document could be reduced to point to that RFC, rather than needing to reiterate.

It may be good to, as a community, re-look at the conclusions section as the place to rework the tone. The choice it presents at the end is, as far as I can tell, the main concern that is being highlighted: that there should be some choice between encrypting transport headers and not encrypting them, depending on what you want the network to be able to do. Practically, I don't see that being the choice before protocol designers. What we see in the case of the Spin Bit in QUIC is that we are adding new mechanisms that are explicit signals, which are arguably outside of the domain of the original notion of transport headers, since the endpoints themselves consume an encrypted form of the information that acts as their true authority at the transport layer. The document brings up IOAM signaling and other mechanisms for measurement, which are also explicit signaling outside of the transport. This seems to be the more obvious conclusion. Of course, clients may not opt into these measurement mechanisms, but that is the choice and evolution that needs to play out. Perhaps the conclusion could lay out something similar to this logic:
- Transport headers are being encrypted, because it has become necessary to preserve privacy and allow for the evolution of transport protocols
- Signals that middleboxes passively read will not be available anymore, which makes certain functionality harder
- If clients want to get the functionality that middleboxes provide while using encrypted transports, they will need to come up with explicit signaling mechanisms



Also, two typos in the document:

Section 1:

... nis a technical ...

Should be:

... is a technical ...

Section 2.3:

... regulators to explore teh ...

Should be:

... regulators to explore the ...