Re: ORIGIN - suggested changes

Nick Sullivan <> Thu, 02 February 2017 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F423129579 for <>; Wed, 1 Feb 2017 16:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.719
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, HTML_MESSAGE=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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kks_VN4-aBcm for <>; Wed, 1 Feb 2017 16:38:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8EA51295EB for <>; Wed, 1 Feb 2017 16:38:33 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cZ5Mc-0002aX-Fa for; Thu, 02 Feb 2017 00:35:02 +0000
Resent-Date: Thu, 02 Feb 2017 00:35:02 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cZ5MV-0002I7-Lu for; Thu, 02 Feb 2017 00:34:55 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cZ5MP-0007X9-Dj for; Thu, 02 Feb 2017 00:34:50 +0000
Received: by with SMTP id r136so539547vke.1 for <>; Wed, 01 Feb 2017 16:34:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O3hUghZiaxfjJl/ZxaW0zc8B426UivaCQhps81wew4E=; b=JhMqqhWIvsJZorUtae8jVbOBT1inC9dqihjrbSqbcqqtecslbfulbM8HW5JlPWbryM nC4rkIe0ETI/MCxh+51G4yORr0q7qY/Pllf+4uB0SOlJrFlz5367ZutNGYuaiTajSH9T lkRidz5JOQ8+G74CywXci1gIEHdWRDFxIYeOz1SwwRQ0vaITpnPmR1OKUqONWtYYWJmn J1XwrJT1jcRPLVZvq4yJP7f2sYwuSsbSNqK9SpLd3Jo6hLbuPT0+wMRepW15lXUC9rSx FSLgj+mOCzP1kjjNi+jQfP4YOLSuMaHzhM6tDC5IUNc3668esZKvyufFgXmm5VhbAqu/ ONXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O3hUghZiaxfjJl/ZxaW0zc8B426UivaCQhps81wew4E=; b=cL7SNvrSqXIzM+GfvOOnVp/exofB8ILio6hVlHxTLDDJQUsze4BUR6XyTV4xcQT/uM b312s1KLVRsA3GmynqZWLEtB3u5s6o5ul9OvWVNwlg9cqIJfmdpYgenZXwyc3HjysGJD GdjPYCtQE7MQJfbLvAY2lbdeemUzyw1mQ+Foopnq6z6XxEXE3WUS/jexmdLHlSTMOfA3 rtr4wh909bZHmeLPP6dfvLs1gpX0ihXr4YX9SMMYtLnPWDcnJOx8+4zKXy9F91F1VRfN qa+usjbY7bxu6MEAzHEU4Hr6yjSQe8cYhMtWWCkPCL4i5VBWiJrKURBwOnIzK6pTEFUk CDSQ==
X-Gm-Message-State: AIkVDXLpCHl5sClyM4Kr0VKJEGw3sI6h2XlVqWHQiXgm+25T4zCdmBuGYWUHFgPJSMjJ9MjlZzIHU537N/fmkQ==
X-Received: by with SMTP id k145mr2755476vkk.29.1485995662970; Wed, 01 Feb 2017 16:34:22 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Thu, 02 Feb 2017 00:34:12 +0000
Message-ID: <>
To: Martin Thomson <>, Ilari Liusvaara <>
Cc: Mark Nottingham <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a11425878a1147d05478153e3"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.143, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cZ5MP-0007X9-Dj 0affde7c19d2c9ec5973fc00ee93e453
Subject: Re: ORIGIN - suggested changes
Archived-At: <>
X-Mailing-List: <> archive/latest/33417
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I think this is a good change.

I agree with Martin that care has to be taken with respect to the scheme
(http vs https). I don't see any particular reason why this mechanism
shouldn't be restricted to https connections.

I also support the idea that for simplicity the origin list should be
additive only. Reducing the starting set to just the SNI (rather than all
the SANs on the cert, which is problematic due to wildcards) is a sensible
way to eliminate the need for pruning operations.


On Wed, Feb 1, 2017 at 2:32 PM Martin Thomson <>

> Inline.
> On 2 February 2017 at 03:42, Ilari Liusvaara <>
> 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.