Re: Spin bit discussion - where we're at

"Brian Trammell (IETF)" <ietf@trammell.ch> Wed, 22 November 2017 10:58 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D866F129406 for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 02:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vGpY04X8fUdk for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 02:58:58 -0800 (PST)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DF71292F4 for <quic@ietf.org>; Wed, 22 Nov 2017 02:58:57 -0800 (PST)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E692B3405AB; Wed, 22 Nov 2017 11:58:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.9567); Wed, 22 Nov 2017 11:58:55 +0100 (CET)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 22 Nov 2017 11:58:55 +0100 (CET)
Received: from vpn-global-dhcp2-174.ethz.ch (account ietf@trammell.ch [129.132.209.174] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36845518; Wed, 22 Nov 2017 11:58:55 +0100
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <C8DDB9E3-C8F9-49CB-8C6D-E381C00AC02D@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_EDB9636C-93AF-49C8-B2CA-8CFC51DE20A1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Spin bit discussion - where we're at
Date: Wed, 22 Nov 2017 11:58:53 +0100
In-Reply-To: <F4F7A438-F30F-406B-9971-DA05DA458B44@netapp.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, QUIC WG <quic@ietf.org>
To: "Eggert, Lars" <lars@netapp.com>
References: <AFEE7BBA-E5DC-4064-AA19-33921EAF4C01@mnot.net> <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <fd09b775-4c0e-9d99-e49c-421212f2e5e4@cs.tcd.ie> <F4F7A438-F30F-406B-9971-DA05DA458B44@netapp.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HZ_VbJQn0om_ews8FgA8P_T35Vo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 10:59:00 -0000

hi Lars,

> On 22 Nov 2017, at 11:35, Eggert, Lars <lars@netapp.com> wrote:
> 
> Hi,
> 
> On 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> What I thought was being requested and what I do think is reasonable
>> is to document a privacy analysis for any quic protocol bits that are
>> visible to the path. Whether or not some or all of that text ends up
>> in some RFC is another day's work.
> 
> for the Spin Bit specifically, the intent was to permanently capture the analysis the DT has done, so that when others review the proposed Spin Bit specification, they can take that as a given and direct any further analysis to other aspects. It made sense to the chairs that that specific analysis should become part of the Spin Bit specification. I think we'd be open to a discussion on whether a broader document analyzing the QUIC wire image would be a better home for this. The main point is for the work that the DT has done to be documented.

Okay. That's somewhat more reasonable than what I read the ask to be ("we're going to gate this on the people who care about this doing some non-trivial amount of work"). Those of us who volunteer (help, please, anyone? :) ) can certainly pull together what we have in a single I-D and ask the WG what more it thinks it needs. To me all this seems pretty clear, but I've been working on this topic for a while.

> For proposals other than the Spin Bit (I think I have seen individual contributors at least mention "loss" and "congestion" bits, but without much detail), we wanted to clarify that we'd like to see an analysis and discussion of their privacy aspects to roughly the same degree as the DT has performed for the Spin Bit proposal.

Ok. A couple of process questions remain open here, then:

(1) can the chairs articulate why, before the finalization of v1, they are proposing to go to a method of working that is somewhat more heavyweight than the issues-and-PRs-plus-ML that enhancements or change requests to the protocol to date have required?

(2) to what proposals, specifically, does this heavyweight process apply? the spin bit and measurement proposals articulated to date? proposals impacting the measurability of the protocol? proposals impacting specific unencrypted bits in headers? all proposals impacting the wire image of the protocol?

Thanks, cheers,

Brian