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

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

Return-Path: <tpauly@apple.com>
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 A53EC1209A9 for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 09:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBV2OONERVjx for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 09:29:50 -0800 (PST)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 C655D120986 for <tsvwg@ietf.org>; Thu, 7 Nov 2019 09:29:50 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xA7HQtdu018722; Thu, 7 Nov 2019 09:29:49 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=mUIcKxy83+dfFotdArY1rp5sxJMIfxfANvhk32GFvws=; b=fmNsX0hMmMjKXxtTqr9GmjJUkG0WLSF7bNIrXeD6d/wougi24nkEN2V34AaZC07StHYM f1+e3xn8zYWNxIyT4Xk4vC9RHCHGUkM1/wyrg2qnK1c1GMEeYgqsI+xq1ZDJhp2WSAnT UZ1xUN5eGUwK0sQIvVpYuwjv+wgCCNgPdU9uMU2JXErgg02fpuChoKI2Hvb0x2PY9o64 C8TRSNY9KErNHF1h6aZGwCW8m5sC11EImwrVq9MJ6vaydqnRQaDza2A6rnqEgHwdu+28 dy6Y9iZ01t0OJ26YMeVetxrXHDmUxxcIhJVAmWpsuxVZDGl8cN3B+Es65eCaNbYGRp1r nw==
Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2w41v6c085-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 07 Nov 2019 09:29:49 -0800
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0M004DC0LNEC70@ma1-mtap-s01.corp.apple.com>; Thu, 07 Nov 2019 09:29:47 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0L00H00ZRUWS00@nwk-mmpp-sz10.apple.com>; Thu, 07 Nov 2019 09:29:47 -0800 (PST)
X-Va-A:
X-Va-T-CD: 6ca8ca8f63305df212074b411a74f5fb
X-Va-E-CD: 67c98ceac6bb71a604aa23a060142496
X-Va-R-CD: f84f189e640d3a0af411e371ea55cce9
X-Va-CD: 0
X-Va-ID: 13ddb6e6-ba8a-4aed-980d-87f0ec96fe29
X-V-A:
X-V-T-CD: 6ca8ca8f63305df212074b411a74f5fb
X-V-E-CD: 67c98ceac6bb71a604aa23a060142496
X-V-R-CD: f84f189e640d3a0af411e371ea55cce9
X-V-CD: 0
X-V-ID: fe6564fd-3b4b-4203-8d5f-a0be8dc14f20
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-07_05:,, signatures=0
Received: from [17.192.171.228] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0M00D6F0LMXH40@nwk-mmpp-sz10.apple.com>; Thu, 07 Nov 2019 09:29:46 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <617F7C76-06D8-49C6-AC87-6B262724251F@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_D45072B7-58BD-42FC-9168-31DF377B31B3"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Date: Thu, 07 Nov 2019 09:29:45 -0800
In-reply-to: <CABcZeBMJPoWPrwqxa3c6saWr-Wp4Up1zg82sbFvwyE9+rQ6gtA@mail.gmail.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <DA05ACC7-2D5C-476B-97F3-EE95461ACB61@apple.com> <CABcZeBMJPoWPrwqxa3c6saWr-Wp4Up1zg82sbFvwyE9+rQ6gtA@mail.gmail.com>
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/KavmDWMhPGbYU0hvhJyd8fsMwoc>
Subject: Re: [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:29:56 -0000


> On Nov 7, 2019, at 9:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> On Thu, Nov 7, 2019 at 9:09 AM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote:
> 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
> 
> Isn't this point already well reflected in RFC 8558?

Yes, I think that the conclusions are indeed the same, and it is important to come to that point. I don't think that makes this document just a duplicate of RFC 8558, necessarily. Having this longer document to go into the explanation of why this conclusion is necessary may be useful, since the message may reach a different audience in this form.

Thanks,
Tommy
> 
> -Ekr
> 
> Tommy
> 
> -----
> 
> 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 ...
>