Re: #148: Reasonable Assurances and H2C

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Tue, 01 March 2016 14:14 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388441A87CD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Mar 2016 06:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 KQYkjvzCWO5E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Mar 2016 06:14:28 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11991A883D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 1 Mar 2016 06:14:28 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aakzp-0006Eh-RR for ietf-http-wg-dist@listhub.w3.org; Tue, 01 Mar 2016 14:09:53 +0000
Resent-Message-Id: <E1aakzp-0006Eh-RR@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aakzl-0006Db-2h for ietf-http-wg@listhub.w3.org; Tue, 01 Mar 2016 14:09:49 +0000
Received: from raoul.w3.org ([128.30.52.128]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aakzj-0004pP-7N for ietf-http-wg@w3.org; Tue, 01 Mar 2016 14:09:48 +0000
Received: from homard.platy.net ([80.67.176.7] helo=[192.168.1.40]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aakzi-00007J-Bz for ietf-http-wg@w3.org; Tue, 01 Mar 2016 14:09:46 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: text/plain; charset="us-ascii"
To: Mark Nottingham <mnot@mnot.net>
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
In-Reply-To: <6CDFF367-D510-4F02-8C23-B9AF504F7A84@mnot.net>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Sun, 28 Feb 2016 16:54:18 +0000
Cc: Barry Leiba <barryleiba@computer.org>, "Julian F. Reschke" <julian.reschke@greenbytes.de>, Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP WG <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Resent-Date: Tue, 01 Mar 2016 15:09:45 +0100
Message-Id: <201602281653.u1SGrWFR027058@shell.siilo.fmi.fi>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
References: <20160209074851.32332.24065.idtracker@ietfa.amsl.com> <20160209182822.C37A959F@welho-filter2.welho.com> <B7164F24-DDA1-4753-8A8B-04809B1965FF@mnot.net> <CAC4RtVCCExJNE0y8480vC1W56NP4XhzfvLs+ASh1Qy-UcDPBNw@mail.gmail.com> <C2145C5A-0255-43F9-A44A-F6C7974CDD4C@mnot.net> <CABkgnnW3-c1qaC_N2UP5TLnPS0rrOYjOYFb4nhUzfQ_8AFsTJA@mail.gmail.com> <072D900D-422E-4168-8DCF-51A739BC9E5A@mnot.net> <CABkgnnWAbKY8RZ5gvjPan3M_-XpjFSau0yDN97H=CfLb0DNL2g@mail.gmail.com> <2DDC5527-43AC-4BD2-8ED9-F68D747A7E0C@mnot.net> <56CFFE31.6090503@greenbytes.de> <12592576-7F89-4309-B97D-753C9402CE7B@mnot.net> <CALaySJJz_FK=JRtEPo1PH5VTJb=XbUJZE711hBLKadrdsvt_Lw@mail.gmail.com> <97553164-A7C4-4F42-B06F-0AD119982669@mnot.net> <CALaySJKU6ztSOrpwQkwS+dFF_+8kcvE3T=34eEWX=reLY6koeQ@mail.gmail.com> <6CDFF367-D510-4F02-8C23-B9AF504F7A84@mnot.net>
Resent-To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3112)
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, AWL=-1.692, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: maggie.w3.org 1aakzj-0004pP-7N 008ee72ac790160e4e1fb74c010ee34e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #148: Reasonable Assurances and H2C
Archived-At: <http://www.w3.org/mid/201602281653.u1SGrWFR027058@shell.siilo.fmi.fi>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31131
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Mark Nottingham <mnot@mnot.net>: (Sun Feb 28 00:10:46 2016)
>> The way to assure the vetting is to say that they must be Standards
>> Track.  Experimental documents might or might not get sufficient
>> vetting.
>> 
>> The way to ensure that people who read this spec can find all the
>> extensions is to make a registry.  Extensions shouldn't generally be
>> "updating" the original spec.
>> 
>> So...
>> You can decide how you think the vetting will be accomplished, but if
>> you want it to be easy to find the new mechanisms, have this document
>> set up a registry and say that new mechanisms MUST be registered
>> there.  Then there's no concern about any "updates" rules with respect
>> to documents from other than Standards Track sources.
> 
> A registry doesn't feel right because this isn't a protocol element. This isn't an extension in the usual sense; it's a controlled loosening of the spec's (security-sensitive) requirements.

Well, "reasonable assurances" can be protocol
element. 

Alt-Svc: h2=":8443"; ma=60000; trust="/.well-known/alternative-services"

(except that token should be shorter, perhaps trust=wk-alt-svc )

Or

Alt-Svc: h2=":8443"; ma=60000; trust=also-options

( ie. "OPTIONS * HTTP/1.1"   should return sama Alt-Svc: -header field
 from original server. )

> However, it doesn't seem like 'updates' is the right way to do this either. Upon reflection, I wonder if we really need either property (at least in such a rigorous form); people will find the mechanisms if they get implemented, and we've been happy to have OppSec as Experimental.
> 
> Anyone have a problem with dropping this?
> 
> """
> Other means of establishing them MUST be documented in an RFC that updates this specification.
> """

Not actually.

( Also just dropping that "updates" works:

| Other means of establishing them MUST be documented in an RFC.

After all that just needs well defined protocol. There is
several possibilities. )


> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

/ Kari Hurtta