RE: Spin bit discussion - where we're at

Roni Even <roni.even@huawei.com> Wed, 22 November 2017 12:03 UTC

Return-Path: <roni.even@huawei.com>
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 4D9CB12941C for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 04:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 url-PxUq4hM3 for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 04:03:53 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 AB2BB12940C for <quic@ietf.org>; Wed, 22 Nov 2017 04:03:52 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 599454ACE2AD8 for <quic@ietf.org>; Wed, 22 Nov 2017 12:03:49 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 12:03:51 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 20:03:47 +0800
From: Roni Even <roni.even@huawei.com>
To: Mark Nottingham <mnot@mnot.net>, Lars Eggert <lars@netapp.com>
CC: Brian Trammell <ietf@trammell.ch>, QUIC WG <quic@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: RE: Spin bit discussion - where we're at
Thread-Topic: Spin bit discussion - where we're at
Thread-Index: AQHTY4dBH8QAeH+8rEa8d6ohEvFvpKMgSxgw
Date: Wed, 22 Nov 2017 12:03:47 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD846111@DGGEMM506-MBX.china.huawei.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> <C8DDB9E3-C8F9-49CB-8C6D-E381C00AC02D@trammell.ch> <CCB67783-2760-44A3-979D-DEDB81ECB187@netapp.com> <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net>
In-Reply-To: <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.203.55]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/jWYDRO2HTLF_pzACeKIlc1jGS2M>
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 12:03:59 -0000

<snip>
> 
> Since you asked earlier: I see item 5 as an extension of item 3. Since the spin
> bit is disconnected from the application payload, it might be used -- both by
> endpoints and networks -- for other purposes, thereby creating incentives
> that reduce its value and/or have unfortunate side effects. If this happens, it
> might not remain fit for purpose (and I've heard a few people expressing
> concern about this). An exploration of this area -- by whoever chooses to do
> so -- would help address those concerns. Not "required", just something we
> think would be helpful to have.
[Roni Even] This concern can be applied to other fields in the clear part of the header. For example the connection id in a peer to peer case. Even in client server an application with a co-operating server can use this long field to whatever they want and it will not break the protocol. We expect that people will  comply with protocol specification but we cannot prevent them from creating non-compliant usages.
> 
> 
> > Part of this is that such proposals should be contributed to the WG in a way
> that lets other contributors understand the rational, design, and implications
> of the proposal, i.e., a somewhat longer and more structured format than
> we'd usually see for GitHub issues and PRs.
> >
> > So yes, we're asking the proponents of new schemes that affect the wire
> image to do a bit more work and produce a more comprehensive proposal,
> compared to what we get in GitHub. But the hope is that this will reduce the
> effort the WG needs to spend overall on understanding and discussing such
> proposals, i.e., we hope for a net win.
> >
> > For the Spin Bit specifically, most of the things that Mark listed exist in one
> way or another, it'll be mostly a short exercise in assembling that material?
> >
> >> (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?
> >
> > My personal view is that I'd like to see this for proposals that affect the
> cleartext wire format in ways that may affect user privacy. For example,
> renumbering the packet types is probably not a change we need to be overly
> concerned with. (I realize this is not a clear-cut definition.)
> 
> Agreed. If data is being added to the cleartext, we'll likely need to examine it
> in a similar way.
> 
> OK, *now* I'm going to sleep.
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>