Re: ORIGIN - suggested changes

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 01 February 2017 16:47 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA16129485 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 Feb 2017 08:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.119
X-Spam-Level:
X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 QyNpDO28gdR1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 Feb 2017 08:47:08 -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 5699B12947D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 1 Feb 2017 08:47:08 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cYy00-0007M5-Fm for ietf-http-wg-dist@listhub.w3.org; Wed, 01 Feb 2017 16:43:12 +0000
Resent-Date: Wed, 01 Feb 2017 16:43:12 +0000
Resent-Message-Id: <E1cYy00-0007M5-Fm@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ilariliusvaara@welho.com>) id 1cYxzu-0007LG-H9 for ietf-http-wg@listhub.w3.org; Wed, 01 Feb 2017 16:43:06 +0000
Received: from welho-filter4.welho.com ([83.102.41.26]) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <ilariliusvaara@welho.com>) id 1cYxzn-00066k-O1 for ietf-http-wg@w3.org; Wed, 01 Feb 2017 16:43:01 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 0B64C2213A; Wed, 1 Feb 2017 18:42:32 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id kTXP1Xtof0ko; Wed, 1 Feb 2017 18:42:31 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 7B7FC27B; Wed, 1 Feb 2017 18:42:31 +0200 (EET)
Date: Wed, 1 Feb 2017 18:42:30 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20170201164230.GA6300@LK-Perkele-V2.elisa-laajakaista.fi>
References: <C3CCA267-F5B5-4827-AC27-9853BDADACDE@mnot.net> <CABkgnnWaN6Kaq28=a+At_YQcZmG_o0-VRMAWBABzdLz-RBxxPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABkgnnWaN6Kaq28=a+At_YQcZmG_o0-VRMAWBABzdLz-RBxxPA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Received-SPF: none client-ip=83.102.41.26; envelope-from=ilariliusvaara@welho.com; helo=welho-filter4.welho.com
X-W3C-Hub-Spam-Status: No, score=-2.9
X-W3C-Hub-Spam-Report: AWL=1.000, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cYxzn-00066k-O1 6208e0f08f3b64b8a84fb20ba18ff939
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ORIGIN - suggested changes
Archived-At: <http://www.w3.org/mid/20170201164230.GA6300@LK-Perkele-V2.elisa-laajakaista.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33409
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>

On Wed, Feb 01, 2017 at 09:11:57PM +1100, Martin Thomson wrote:
> These seem like good changes in principle.  I've left a few comments
> on the PR that say much the same as below...
> 
> On 1 February 2017 at 17:50, Mark Nottingham <mnot@mnot.net> wrote:
> >   - Removes the requirement for a supporting client to check DNS
> to determine if the server is authoritative, when ORIGIN is received
> 
> You should do something about http:// resources.  This means that this
> is a perfect http:// hijacking mechanism.  I don't think that was the
> intent.  I would prefer if this were limited to HTTPS, which at least
> leaves certificate validation.

I thought this mechanism is strictly limited by the normal HTTP/2
authoritativeness. Which impiles that it is only usable with
certificate validation. 

> >   - Redefines the initial Origin Set as whatever SNI included (if anything).
> 
> If you do support this feature, the second change leads to having no
> valid origins initially if you don't use SNI.  It also could be read
> to prohibit coalescing as we do today.  Presumably the set is whatever
> we have today until you see an ORIGIN frame.  You should probably say
> something about that.

I think server should start with resetting the list with whatever
origins it is authoritative for. Especially in case client has some
funny ideas about that (e.g. due to wildcard certificates[1]).

> > Some people have also been talking about simplifying ORIGIN, e.g.,
> > by removing some of the set operations. I think we should talk about
> > that on list first.
> 
> Let me put my stake in the ground.
> 
> The current design is just a little too complicated.  The ability to
> clear the set and remove from the set is where a lot of that
> complexity comes from.

You mean assuming that server can lose authoritativeness over an
origin? Because once you assume that, the reset/remove operations
folow with relatively little complexity.
 
> Let's say that if you want to start over, then you really start over:
> make a new connection in that case.  The need to remove is greatly
> diminished by starting with a very small set.  If you do need to
> cleave off an origin after previously advertising it, then ALTSVC is
> available and much more graceful than anything this provides.  Removal
> - as specified - is still subject to races and therefore violence,
> since there is no acknowledgment.

The operation is just fundamentially racy, due to finite speed of
light. And if you really wanted to (and I this is a bad idea), you
could request ACK from client, even if ORIGIN didn't explicitly support
ACKs.

> That just leaves the frame being able to add origins to the set that a
> client might consider using.  That's pretty easy to manage.  Anything
> you have ever seen in an ORIGIN frame is a candidate.  Servers can add
> to the set any time they like (likely in response to serving content
> that references other origins), and clients can choose to forget
> origins if the list ever gets too long for them to manage.



[1] The use of those, in contexts where this is hazardous might increase
in te future, thanks to Chrome planning to require Certificate Transparency
and having no explicit redaction mechanism. Which leaves wildcard
certificates as the only option to redact anything.


-Ilari