Re: ORIGIN - suggested changes

Martin Thomson <martin.thomson@gmail.com> Wed, 01 February 2017 22:31 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 B052B1295DF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 Feb 2017 14:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.719
X-Spam-Level:
X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 z5qePh9VAQBX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 Feb 2017 14:31:41 -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 69F761295BA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 1 Feb 2017 14:31:41 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cZ3P0-000708-DC for ietf-http-wg-dist@listhub.w3.org; Wed, 01 Feb 2017 22:29:22 +0000
Resent-Date: Wed, 01 Feb 2017 22:29:22 +0000
Resent-Message-Id: <E1cZ3P0-000708-DC@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1cZ3Ov-0006zN-MS for ietf-http-wg@listhub.w3.org; Wed, 01 Feb 2017 22:29:17 +0000
Received: from mail-qt0-f175.google.com ([209.85.216.175]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <martin.thomson@gmail.com>) id 1cZ3Oo-00076N-Dy for ietf-http-wg@w3.org; Wed, 01 Feb 2017 22:29:12 +0000
Received: by mail-qt0-f175.google.com with SMTP id w20so215965632qtb.1 for <ietf-http-wg@w3.org>; Wed, 01 Feb 2017 14:28:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iKUGEP9F+ZudQkOf0hKSQrdflmWoFOfgGHFzwAmT2tM=; b=hcDCL1HEZ+0vmJ8pY8N4zyVmTKEWnvEhFRt30em/rzVZpwxg/cLVI9jwxY3QUXixki 6ehwYUyJTb1OcIfH0OuI5YVv4SbuhylENX8BkEA1c1GzIyaY1fpH20AqThnjCQmeb3Ah RFep18z8+oPxmZorhBfb4m1D0Rv63DAUIuIOPkjXYQxtgZ33XMCnkd7/7Qr9k+SpKL3p qEEmMDdwelFmepJbiQmwh90pe/SpwtyiJ8Ny9ikwkWWu1+yegFmqg+5kikiQihTnjeh2 PqDnX2pDDWEg38qb3FHWlXwIX2KnSyQl1AsdqCpbXRB3gAeAf5fig5zcoLfZ0Wz2QdCb fOGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iKUGEP9F+ZudQkOf0hKSQrdflmWoFOfgGHFzwAmT2tM=; b=awXgtEij4rgcBRT0wzkbrtgvMvwnyO+zrtMf66yOfSz50T2GxiHB8Cha2uglQ6fO9v KlkPmGPf5jT+1part01OtdRrIpRHSW2I8Cxm9swdUil6RD9dsW4ZeZmKO1+V0e4VvC6G DJMeNYl+6Rgn5xHXsmBW887NUXAMGU/B8cRIwSgcoM2OtGxfsFVhhYwRx64/pB08Cj6+ VKcqePdzlCAJVuPDcpAEAYC+dM/4sY38aLpvrDXAsD9cuzk9qgNTyYfE6ToSxmlWRQWZ oR+mQlvmGSlf0l6merWxOiwk+zQ4WWz1zkTYbynp9z3Ovnk9+yElAYWUsrBsjqvLZmdt oCqg==
X-Gm-Message-State: AIkVDXI6njcnuGUWgF9mOhJGxfvxT+Ys0Wz8P1AtkPTCpPkwgDtmR25Wq8MA6ZZ8QVy5rvkMS1mToVfwTp+sKw==
X-Received: by 10.200.39.200 with SMTP id x8mr4999849qtx.159.1485988123234; Wed, 01 Feb 2017 14:28:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 1 Feb 2017 14:28:42 -0800 (PST)
In-Reply-To: <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> <20170201164230.GA6300@LK-Perkele-V2.elisa-laajakaista.fi>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 2 Feb 2017 09:28:42 +1100
Message-ID: <CABkgnnVjB9vBt5hSWuQpz994m1mET44pbbbUoz=BK=Qcbm0YYA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.216.175; envelope-from=martin.thomson@gmail.com; helo=mail-qt0-f175.google.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=0.127, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cZ3Oo-00076N-Dy b0a335d0edb8559cd765b462c356b69c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ORIGIN - suggested changes
Archived-At: <http://www.w3.org/mid/CABkgnnVjB9vBt5hSWuQpz994m1mET44pbbbUoz=BK=Qcbm0YYA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33416
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>

Inline.

On 2 February 2017 at 03:42, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>> 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.

HTTP/2 defines authoritative for HTTP as well as HTTPS (leaning
heavily on the definitions in HTTP/1.1).  We often fall into the habit
of thinking that HTTP/2 implies HTTPS, but that's not how the
specification is written.

> 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]).

My hope is that there should be no need for a reset now that the
initial set only includes the SNI host.  The server merely has to make
claims about additional origins.  Once it does so, those funny ideas
go away.  Especially if ORIGIN can't express wildcards.

> 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.

The reason that I expect a server would want to disavow an origin
isn't anything to do with losing authoritativeness, but more with
operational constraints.  If the server is a gateway to multiple
back-ends and one of those back-ends wants to shift things around,
killing all affected connections is feasible, but a blunt instrument.

In any case, I think that this is rare enough not to warrant special
complexity in the specification to handle. And I mean any complexity
at all.

If the client determines that the server is no longer authoritative,
then the client stops sending requests over that connection.  That
doesn't need any extra signaling.

>> 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's my point, I don't think that we need to.  Any situation that
needs to happen immediately can be handled with a 421 (Not
Authoritative) status code.  For everything else, use ALTSVC.