Re: [Stackevo] [IAB] draft-hardie-path-signals and draft-trammell-wire-image
Alissa Cooper <alissa@cooperw.in> Fri, 13 April 2018 20:08 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: stackevo@ietfa.amsl.com
Delivered-To: stackevo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0452C127AD4; Fri, 13 Apr 2018 13:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=cooperw.in header.b=h1tQnwjB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fdnlGxvs
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 haZJySKPGOHt; Fri, 13 Apr 2018 13:08:09 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43277127978; Fri, 13 Apr 2018 13:08:09 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 836EC21C12; Fri, 13 Apr 2018 16:08:08 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 13 Apr 2018 16:08:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=nZkXqsennkx9LgDmOMs7UhjjBG4W4MeIguuWhLogiDY=; b=h1tQnwjB j3TJw8TBT8SikktBnW1s31ZZ6GbXS5wFZi5VSUAVp1J9xLMii5Cpr+YVSyge7L23 BWoq4XAHvxce0tGj2OCNLB/Mbr3bINwpw1LplTKCzkiGmTOonFPP5T2R3RGmvC86 MR92mG46XkYSb0k+RqixBIwWHujm7ahFJ+aSIFr4xPpKqZSnCTu93mLqQW834mFM yGkOdyBC3MH+0oVNU/aY0ox2CCSLG/PmRl37TGu+iezdBxRhn+OXyXTJTek+z0Nf z51zES0CaY0bF7hk7eVfOakitapRFmDKVe+D1zQzoWrVyToJ7YB+rnBmP7yb/3KY YBf1rtc9o1HvoA==
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-sender :x-me-sender:x-sasl-enc; s=fm2; bh=nZkXqsennkx9LgDmOMs7UhjjBG4W4 MeIguuWhLogiDY=; b=fdnlGxvsRenVPp7ZNb7/jHspBVm++wSUaOcJEeOLZ30Zj LuOLVpI1y5IHQaa2m1vf5oS5bbeMdLtESO7bGZtU8MXuMdp98JO9H2XbTmVkAnLx f6jXbOTxpLTpcLsvdnVfKvMmw/CQMN6FHMLiO0+49+eZHRQT1Z3Il7B3iBqtqQti nkS3nTsGoHkGlLCxJCttSvq1VXfmSFIUKz1UTsKdkxwVm0Mz+eH7a9jALCZEKbJe mwVvmTGq+zlgjDTJTmJvcVjVFgl2sJTIZ+cYmI+jgbqQ6ChyiyDUdbLI5Jjeokai ClAf8VqPH7P83cUMdIwcrF/l9FUajksnuDR7k1gUA==
X-ME-Sender: <xms:KA7RWlQnsi72A4CBeBMJnMX0tFXThSkrrx4G0-S_kU4LtHqOc_tosA>
Received: from rtp-alcoop-nitro3.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id C1036E446F; Fri, 13 Apr 2018 16:08:07 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8930A33C-0696-4E06-AEDB-96F2DA1B54A0"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <C986EAB5-CFE3-49AF-A19A-B087E63EE365@trammell.ch>
Date: Fri, 13 Apr 2018 16:08:06 -0400
Cc: IAB IAB <iab@iab.org>, Stack Evolution Program <stackevo@iab.org>
Message-Id: <30FF384D-0451-4959-82CF-AB64C176CF19@cooperw.in>
References: <C986EAB5-CFE3-49AF-A19A-B087E63EE365@trammell.ch>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/4rcQOEKPkUMWI2d-P9G3hOQuRso>
Subject: Re: [Stackevo] [IAB] draft-hardie-path-signals and draft-trammell-wire-image
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IP Stack Evolution Program Mailing List <stackevo.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo>, <mailto:stackevo-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo/>
List-Post: <mailto:stackevo@iab.org>
List-Help: <mailto:stackevo-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo>, <mailto:stackevo-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2018 20:08:12 -0000
Couple of mostly random thoughts ... > On Apr 4, 2018, at 4:50 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote: > > Greetings, > > After discussion at our Friday morning London meeting (and thanks, all, on the program for your remarkable Stack Evolution Program would like the IAB to consider two documents for publication on the IAB stream: > > https://tools.ietf.org/html/draft-trammell-wire-image-03 <https://tools.ietf.org/html/draft-trammell-wire-image-03> > https://tools.ietf.org/html/draft-hardie-path-signals-03 <https://tools.ietf.org/html/draft-hardie-path-signals-03> In the long-ago of the IAB privacy program, Stephen Farrell and I had an exchange with George Danezis about doing some reviews of specific IETF protocols’ susceptability to traffic analysis. That never happened, but George did express an interest in doing some sort of work in the IETF. He might be a good reviewer and/or contributor to these documents, particularly to add some rigor to the bits about packet timing and size information. There has been some discomfort expressed with using the term “consent” in the context of communications consent for RTCWEB. I didn’t particularly think that was actionable in the RTCWEB context, but I do worry a bit in the general context that consent connotes a user’s involvement, when clearly that is not how the term is used in these documents. Might be good to find a different way to describe the same concept. > > The wire image draft describes what a protocol's wire image is, and explores the situations that arise when a protocol splits its visible wire image from the information it uses for its own operation. (It started as a draft I wrote during the extended Singapore plenary discussion on encryption of protocols, riffing off Ted's observation from the dais that protocols with explicit wire images were a completely new thing, in part to describe what I mean when I use the term.) > > The path signals draft recommends that protocol machinery be confidentiality protected, and that any signal exposed to on-path devices (outside confidentiality protection) be *explicitly* so exposed and integrity protected. It reiterates that metadata injection is considered harmful. As a product intended for broad consumption by the IETF community, I think the path-signals document needs to be more clear about the scope of its recommendations. Limited to transport protocols? Limited to new transport protocols? More generally, both of these documents are probably not easily understood by the parts of the community that have not been closely following spud/plus/quic. More context would help if the idea is to broaden the conversation (although I’m not sure that is the idea). Thanks, Alissa > > Thanks, cheers, > > Brian (stackevo lead hat)
- [Stackevo] draft-hardie-path-signals and draft-tr… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Martin Thomson
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Mark Nottingham
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Mark Nottingham
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Spencer Dawkins at IETF
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Mirja Kühlewind
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Martin Thomson
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Alissa Cooper
- [Stackevo] draft-thomson-use-it-or-lose-it Brian Trammell (IETF)
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Ted Hardie
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Brian Trammell (IETF)
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Ted Hardie
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Martin Thomson
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Aaron Falk