Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

"Martin Thomson" <mt@lowentropy.net> Tue, 05 November 2019 05:09 UTC

Return-Path: <mt@lowentropy.net>
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 1098912002F; Mon, 4 Nov 2019 21:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=L8gSwNln; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xm35xXjh
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 84d2uvG4LJgO; Mon, 4 Nov 2019 21:09:38 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EA4120020; Mon, 4 Nov 2019 21:09:38 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3496821FE5; Tue, 5 Nov 2019 00:09:37 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 00:09:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=WF6DxDbkIL0Y8Kl8ix6kG7pvYjQv WTzRtJIvU2C3WOY=; b=L8gSwNlnAYxruPbKrDltlZ6L9BJSertrmtrB8R/uWA1Q fiMOZVYkoJdZRI7HP13gSmomBBq2Ty52ZC+7RscL7iZYHk0TyqZzBhg5bKSonA9I 0eQZfDI0CDnNQtNc9rqVi6uv0OLTNLN5wutIYEz8zlzih9JM7eK3QhPPjtvNhoN4 c8NpZ62Slx3c1XqWX7gyaVXKM+K9VEG1SyjKka+E19ZzN7OBFO5EHJ6T0fziQ6i8 7ryyOSBxlkdcUbMKcH5cTVfCRiNoHNeuQzkQ6BR0MUx3lthRFiYDYmnU3iQlw7S7 vx9NVgOkOuDbZGvL9YFw2PI/hRuJwUV25H0CjfUejg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=WF6DxD bkIL0Y8Kl8ix6kG7pvYjQvWTzRtJIvU2C3WOY=; b=xm35xXjhaIwQ9p5pZm0WqB uqF6iwInZrxY9NznecZGMRuw6jCjIJSyOGLPUI5m2E/Rw/JAdublt47ryeoxs3xQ pZTzJ644fS2ywH10jVRzxcs1vUBOBq+iywUGvStPqMPK10hFLk493lRLb4wauz5R AA7Ae9YXcLjVlPs/zpoXZeQf72NAjQ8ao6DYTaw6SlKEAf9NgYtdQpNqewUNl0nO BI+d5Hi8qGGWvr5VS/wY1FYjHvuuWBTomEkZw8U/0DeR/YRVyHuGv8Ez7reAcwKM ecRud7pXxelHQdUiwG6MtPoJm3mX92wBxwg2rLBEv8TytSA6BFVLshDx6QK+U5Fg ==
X-ME-Sender: <xms:EATBXbT_xcVWI45UJQt7LpWsSTzioha6l3lJsSE6OwxNDRnyae1i5w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddugedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:EATBXSX3rJ7rV5d3Kt5HBSc7gzHtXzgHYAumNLbHCVGSJpppCX1eTw> <xmx:EATBXaYAHvaRm9ntiPFsPrkomZR5qUMFkWQD87jWL4rvxUN_pz_DZQ> <xmx:EATBXb6o6SugvH9RF9ga1mfjq95e5gfVoXoPnIzU1opqODsszhC7Gg> <xmx:EQTBXZTnNftKbQw61aRJ_hAW8H8jzdQDOr9aIR5kCMXTuTTxolWuFg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8B584E00A3; Tue, 5 Nov 2019 00:09:36 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <8b26fae5-0db0-48b0-859e-1a5faf6310ea@www.fastmail.com>
In-Reply-To: <CALx6S36YQSX2yGaqpK7cVrGdKg1JqBpwuYPD9YxeDy3Dd_Gk8w@mail.gmail.com>
References: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com> <CALx6S35bSAa_zq=HsF-3e9qC-vRNFRu6dn+O4ak4Hi+c=Tmz5A@mail.gmail.com> <bbb870cd-033b-4a99-ba0c-fbd9c965660b@www.fastmail.com> <CALx6S36YQSX2yGaqpK7cVrGdKg1JqBpwuYPD9YxeDy3Dd_Gk8w@mail.gmail.com>
Date: Tue, 05 Nov 2019 16:09:16 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "Tom Herbert" <tom@herbertland.com>
Cc: saag@ietf.org, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/wUQwiWULme6nsacRJkDzTFRxcNM>
Subject: Re: [tsvwg] =?utf-8?q?=5Bsaag=5D_Comments_on_draft-ietf-tsvwg-transp?= =?utf-8?q?ort-encrypt-08=2Etxt?=
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: Tue, 05 Nov 2019 05:09:40 -0000

On Tue, Nov 5, 2019, at 15:36, Tom Herbert wrote:
> > Please refer to draft-ietf-quic-manageability for that discussion.
>
> I looked at that draft. While it does mention RFC7605, the explanation
> for how non-QUIC packets that match port 443 aren't misinterpreted
> isn't particularly satisfying. Other than assuming port number match
> is sufficient, the recommended approach seems to be for middleboxes to
> track flows by handshake. But, that then requires state to be
> maintained and implies that packets for the flow must be consistently
> be routed through the same device (a common problem for any stateful
> device in the network). I don't think the QUIC spin bit serves as an
> exemplar for reliably exposing transport layer information in a
> transport protocol that is otherwise encrypted.

Yeah, not saying that this is ideal, but it's what we're handing out.  Well, some of us might, I don't think that our implementation has any intention of leaking anything at this stage.

Note also that QUIC allows for migration where the new path will not see the handshake.

I don't think that there is a lack of interest in this subject, just that there is no real drive toward finding e2m and m2e signaling that will be deployed.  Personally, my interests are aligned more with removing signals, not adding them.