Re: [Int-area] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
Paul Vixie <paul@redbarn.org> Tue, 09 June 2020 17:45 UTC
Return-Path: <paul@redbarn.org>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7D33A0C3A; Tue, 9 Jun 2020 10:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 pyGh4iqmW7AF; Tue, 9 Jun 2020 10:45:36 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071CE3A0C35; Tue, 9 Jun 2020 10:45:34 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 64DE5B07D1; Tue, 9 Jun 2020 17:45:34 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Cc: int-area <int-area@ietf.org>, IETF SAAG <saag@ietf.org>, "Black, David" <David.Black@dell.com>
Date: Tue, 09 Jun 2020 17:45:33 +0000
Message-ID: <19653098.bRLUaAYVpO@linux-9daj>
Organization: none
In-Reply-To: <MN2PR19MB40450EE357BEECD723AB06F183820@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <MN2PR19MB40450EE357BEECD723AB06F183820@MN2PR19MB4045.namprd19.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/CvEKUFKi9Yitwtt8cGoWF7BckyQ>
Subject: Re: [Int-area] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 17:45:38 -0000
On Tuesday, 9 June 2020 01:41:40 UTC Black, David wrote: > This email announces a limited-scope 3rd TSVWG Working Group Last Call > (WGLC) on: > > Considerations around Transport Header Confidentiality, Network > Operations, and the Evolution of Internet Transport Protocols > draft-ietf-tsvwg-transport-encrypt-15 > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ > > This draft is intended to become an Informational RFC. This WGLC has > been cc:'d to the SAAG and INT-AREA lists courtesy of the breadth of > interest in this draft, but WGLC discussion will take place on the TSVWG > list (tsvwg@ietf.org<mailto:tsvwg@ietf.org>) - please don't remove that list > address if/when replying with WGLC comments. the goals of "prevention of network ossification" are incompatible with layering exits such as a router using non-routing header information to guide its operations. this isn't a new constraint collision -- consider OSPF ECMP which needs to examine the TCP or UDP header to find a 5-tuple to hash upon. as this draft is informational, objections of the form "it says something that is untrue or at least confrontational" or "it lacks something essential" are in scope and the answer should be "send a pull request". whereas objections of the form shown in the e-mail summary (archival) thread you referenced: (https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/) > I would like to see this useful content in a BCP document once we have > enough information to actually recommend something. are out of scope because this document isn't making any recommendations, and (ibid) > Having an IETF Consensus RFC that is so heavily weighted on the side of > "this is how encryption inconveniences us" and so light on "these are the > attacks we are preventing" gives a misleading picture of the IETF > community's view of the relative priority of these concerns. are regressive, leading back to the result of "send a pull request" since the consensus being sought isn't about a recommendation but rather a depiction of known considerations. unknown considerations should not concern us, since those always exist and cannot be addressed until they make themselves known. known considerations which are missing, incomplete, or misleading in the text as drafted, should be fixed. i have two objections, both of which are inoperable at this time due to the limited scope of this WGLC. (you're asking for pass/fail, and the time for me to have suggested these changes has passed.) first, section 7.2 could do some real good by enumerating local operating system and local network policy as reasons why a transport protocol should have low-entropy markers. on many endpoints and within many networks, uncharacterized traffic will be dropped. the advance of DoH has caused and will continue to cause broader adoption of required explicit proxies to prevent uncooperative insiders from bypassing DNS policy controls. QUIC is going to cause UDP to become a privileged operation, denied except for classifiable traffic, to prevent similar bypasses. a brief examination of these deployment obstacles to PM-resistant transport deployment would help inform the manageability draft, and may even motivate a secure proxy discovery protocol similar to what the ADD WG is working on for secure RDNS discovery. it's clear that DHCP in its current form will never be used to communicate any endpoint parameter which has security value. a transport protocol which permits an on-path device to authentically deny an unclassifiable flow will be deployed more quickly and more widely, and so a mention of these tensions in section 7.2 might accelerate darwinism here. second, the absence of signaling within the IP and IP6 headers to drive the advancement of congestion management is a form of ossification, and should be blamed here. the needs of L4S or SCE or similar should not have a bearing on QUIC or for that matter even on TCP. so, when discussing anti-ossification as a goal, this document could highlight that previous ossification has created many of the tensions the document will go on to describe in detail. this bit of history won't be known by most readers, and could provoke cognitive dissonance if left untreated. given the inoperable (because: late) nature of my objections, i support publication of this draft. thank you for giving us a chance to comment. vixie
- [Int-area] 3rd WGLC (limited-scope): draft-ietf-t… Black, David
- Re: [Int-area] [tsvwg] 3rd WGLC (limited-scope): … Paul Vixie
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Kyle Rose
- Re: [Int-area] [tsvwg] 3rd WGLC (limited-scope): … Roni Even
- Re: [Int-area] 3rd WGLC (limited-scope): draft-ie… Tom Herbert
- Re: [Int-area] [tsvwg] 3rd WGLC (limited-scope): … Holland, Jake
- Re: [Int-area] [tsvwg] 3rd WGLC (limited-scope): … Gorry Fairhurst
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Eric Rescorla
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Hannes Tschofenig
- Re: [Int-area] [tsvwg] [saag] 3rd WGLC (limited-s… Colin Perkins
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… mohamed.boucadair
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Hannes Tschofenig
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Kyle Rose
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Dirk.von-Hugo
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Joseph Touch
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Behcet Sarikaya
- Re: [Int-area] [tsvwg] [saag] 3rd WGLC (limited-s… tom petch
- Re: [Int-area] [tsvwg] [saag] 3rd WGLC (limited-s… Spencer Dawkins at IETF
- Re: [Int-area] [saag] 3rd WGLC (limited-scope): d… Ruediger.Geib