Subject: Re: ORIGIN - suggested changes

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Feb 2017 21:11:57 +1100

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 <[email-masked]> 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.

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

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

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.

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.

As a discretionary mechanism in this way, this could be a lightweight
feature that nicely complements ALTSVC.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 1 Feb 2017 18:42:30 +0200

On Wed, Feb 01, 2017 at 09:11:57PM +1100, Martin Thomson wrote:
> >   - Removes the requirement for a supporting client to check DNS
> to determine if the server is authoritative, when ORIGIN is received
> 

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

> we have today until you see an ORIGIN frame.  You should probably say

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

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

> 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

---

From: Frederik Deweerdt <[email-masked]>
Date: Wed, 1 Feb 2017 08:46:32 -0800

Hello,

On Wed, Feb 1, 2017 at 2:11 AM, Martin Thomson <[email-masked]>
wrote:
[...]
> we have today until you see an ORIGIN frame.  You should probably say

I'm confused by the "if you don't use SNI part", how can that happen with
RFC 7540, 9.2. stating:
+    The TLS implementation MUST support the Server Name Indication (SNI)
+    [TLS-EXT] extension to TLS.  HTTP/2 clients MUST indicate the target

I've seen HTTP/2 servers reject the connection if the client doesn't send
an SNI.

Frederik

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2017 09:18:27 +1100

On 2 February 2017 at 03:46, Frederik Deweerdt <[email-masked]> wrote:
> I've seen HTTP/2 servers reject the connection if the client doesn't send an
> SNI.

My memory was clearly faulty.  Mark's "if anything" comment lead me to
infer that SNI was optional.  As it isn't, this isn't a problem.  The
point about coalescing stands.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2017 09:28:42 +1100

Inline.

> authoritativeness. Which impiles that it is only usable with

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.

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

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

> could request ACK from client, even if ORIGIN didn't explicitly support

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.

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 02 Feb 2017 00:34:12 +0000

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.

Nick

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Feb 2017 12:12:56 +1100

> On 1 Feb 2017, at 9:11 pm, Martin Thomson <[email-masked]> wrote:
> 

Yes. IIRC our final position on this with oppsec was that http can't be coalesced; this doc should reinforce that. We should also point out that this only works on h2, not h2c.

> we have today until you see an ORIGIN frame.  You should probably say

Ah, you fell into my carefully laid trap...

I'll adjust the text.

> since there is no acknowledgment.

The big use case for this is wildcard certs; origins that use them need a way to say "everything except *those*", which means removal. It also means we need either a wildcard mechanism, or some way to say "everything covered by the cert."

I don't buy the argument that removal itself adds complexity. Implementations already need to remember what origins they received a 421 for, so they already have the concept of origin set removal.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2017 10:23:18 +0900

> I don't buy the argument that removal itself adds complexity. Implementations already need to remember what origins they received a 421 for, so they already have the concept of origin set removal.

Well, you just established why it might be unnecessary.  The gain here
is in the client not sending a request to the wrong place.  But if
this is rare enough, then that cost is probably bearable.

The "everything except those" case doesn't concern me that much.  I
know it's relatively common, but it is fairly rare that the set of
origins that are used is not easily enumerable, or incrementally
discoverable.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Feb 2017 12:30:51 +1100

> On 2 Feb 2017, at 12:23 pm, Martin Thomson <[email-masked]> wrote:
> 

Right, but the whole point of ORIGIN is to avoid those situations. 

> The "everything except those" case doesn't concern me that much.
>  Iknow it's relatively common, but it is fairly rare that the set of

Spoken like a true browser vendor :) 

It'd be good to get a bit more data here from server-side folks. Anyone share this concern? I note that Nick seems to be OK with it.

Cheers,

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 2 Feb 2017 13:46:21 +0100

> Am 02.02.2017 um 02:30 schrieb Mark Nottingham <[email-masked]>:
> 
> 

The feedback from Apache httpd users which have wildcard cert setups is: do not enable h2. 

From their PoV, they have a config running with HTTP/1.1 for years now, enabled h2 and all hell broke lose. Some sites work, some don't and that also depends on what your browser did before *). They do not want to change their setups, they expect h2 to just work or they will not use it. 

Currently, ORIGIN frame is not supported by httpd. My expectation is, once added, by default the server would send an empty ORIGIN frame, implying that the current connection should only be used for the SNI host. If I read the current spec correctly. (And btw. which browser plans to support it?)

Additionally, having configuration directives per virtual host where an admin can add other ORIGINs for connections to this very host, seems a good first step. My goal is to have the default "just work" in case of wildcard certs and require intentional configuration by the admin to optimize from there.

The feedback I am receiving on 421 response and HTTP_1_1_REQUIRED handling is not great. And it's difficult to debug for most people.

Cheers, Stefan

*) httpd replies with HTTP_1_1_REQUIRED when a stream encounters a TLS setup for a site that is not the same as the current connection.

> Cheers,

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

---

From: Mike Bishop <[email-masked]>
Date: Thu, 2 Feb 2017 18:10:59 +0000

That use of 1_1_REQUIRED surprises me; I would think 421 would be the appropriate response there, too, since the request needs to be made on a separate (but still HTTP/2) connection.

-----Original Message-----
From: Stefan Eissing [mailto:[email-masked]] 
Sent: Thursday, February 2, 2017 4:46 AM
To: Mark Nottingham <[email-masked]>
Cc: Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: ORIGIN - suggested changes

>> Well, you just established why it might be unnecessary.  The gain 
>> here is in the client not sending a request to the wrong place.  But 
>> if this is rare enough, then that cost is probably bearable.
> 

Cheers, Stefan

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 2 Feb 2017 19:45:12 +0100

You are correct that the most frequent case is a 421 answer. The 1_1_REQUIRED is returned when the TLS layer detects a renegotiate attempt. Often, these are triggered by client certs, but some people seem to also require other ciphers in certain locations (don't ask my why).

I am not saying that all the confusion stems from HTTP/2. It's merely that the TLS+HTTP/1.1 combination made things possible that, at the moment, are not possible with h2. I know your and other peoples efforts to improve this. However until then, I'd like to offer a "safe" default in the server. I hope ORIGIN will allow me to do that.

> Am 02.02.2017 um 19:10 schrieb Mike Bishop <[email-masked]>:
> 

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Feb 2017 11:43:03 +1100

I've done some more updating:
  https://github.com/httpwg/http-extensions/pull/285

At this point, the diff isn't too helpful, so see attached.

Changes include:

1. Removing set manipulation flags
2. Reserving some flags for future backwards-incompatible extensions (which makes me feel a bit better about #1)
3. Note impact upon Server Push
4. Added IANA Considerations and Operational Considerations
5. Lots of clarifications

Feedback welcome, as always.

> On 2 Feb 2017, at 12:30 pm, Mark Nottingham <[email-masked]> wrote:
> 
>

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 3 Feb 2017 14:22:24 +0100

Looks good to me.

*But* I think I would be good to have an ORIGIN frame that says: please revert your ORIGIN set back to undefined for this connection (and erase all 421 derived information).

This should be less complex than individual removes and provide for changes on very long lived connections.

-Stefan

> Am 03.02.2017 um 01:43 schrieb Mark Nottingham <[email-masked]>:
> 
> <draft-ietf-httpbis-origin-frame.html>
> 
> 

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

---

From: Patrick McManus <[email-masked]>
Date: Fri, 3 Feb 2017 17:21:11 +0100

Mark - thanks for this. I think we're really onto something and have hit on
the right balance of usefulness and simplicity. I've made a couple PR
comments - but briefly I think the only issue I might want to think harder
about is the interaction with ports that you have specified wrt alt-svc.

I'm eager to implement in firefox and I know of at least 2 CDNs and 1
server that are eager as well.

-P

On Fri, Feb 3, 2017 at 1:43 AM, Mark Nottingham <[email-masked]> wrote:

> 2. Reserving some flags for future backwards-incompatible extensions
> (which makes me feel a bit better about #1)
> >>> I don't buy the argument that removal itself adds complexity.
> Implementations already need to remember what origins they received a 421
> for, so they already have the concept of origin set removal.
> >>
> > It'd be good to get a bit more data here from server-side folks. Anyone
> share this concern? I note that Nick seems to be OK with it.
> >
> > Cheers,
> >
> > --

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 4 Feb 2017 11:49:35 +1100

Hey Stefan,

> On 4 Feb 2017, at 12:22 am, Stefan Eissing <[email-masked]> wrote:
> 
> Looks good to me.
> 

I hear what you're saying, but so far the strongest blocker for this spec has been complexity, so I'd like to hear what others (especially implementers on the client side, where most of the work is) think.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 5 Feb 2017 14:44:36 +0100

I feel that ORIGIN has succeeded in getting unparked by being very attuned
to specific use cases.. first it turned into a "sni only" settings bit, and
now (based on use case) an explicit declarative opt-in. to me - that feels
right.

I view this as declarative - if your configuration changes GOAWAY or
Alt-Svc are probably better ways to manage it. I spitballed that we should
only allow 1 ORIGIN frame, but that basically isn't plausible due to size
limitations, I don't really expect it to be used to dribble updates over
time. (but normatively enforcing that would require some kind of
CONTINUATION world I hope nobody wants to entertain.)

-P

On Saturday, February 4, 2017, Mark Nottingham <[email-masked]> wrote:

> Hey Stefan,
>
> > On 4 Feb 2017, at 12:22 am, Stefan Eissing <[email-masked]
> <javascript:;>> wrote:
> >
> > Looks good to me.
> >
> > *But* I think I would be good to have an ORIGIN frame that says: please
> revert your ORIGIN set back to undefined for this connection (and erase all
> 421 derived information).
> >
> I hear what you're saying, but so far the strongest blocker for this spec
> has been complexity, so I'd like to hear what others (especially
> implementers on the client side, where most of the work is) think.
>
>
>
>
> >
> > -Stefan
> >
> >> Am 03.02.2017 um 01:43 schrieb Mark Nottingham <[email-masked]
> <javascript:;>>:
> >>
> >>> On 2 Feb 2017, at 12:30 pm, Mark Nottingham <[email-masked]
> <javascript:;>> wrote:
> >>>
> >>>
> >>>> On 2 Feb 2017, at 12:23 pm, Martin Thomson <[email-masked]
> <javascript:;>> wrote:
> >>>>
> >>>> On 2 February 2017 at 10:12, Mark Nottingham <[email-masked]
> <javascript:;>> wrote:
> >>> It'd be good to get a bit more data here from server-side folks.
> Anyone share this concern? I note that Nick seems to be OK with it.
> >>>
> >>> Cheers,
> >>>
> >>> --

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 6 Feb 2017 11:17:19 +0100

> Am 05.02.2017 um 14:44 schrieb Patrick McManus <[email-masked]>:
> 
> I feel that ORIGIN has succeeded in getting unparked by being very attuned to specific use cases.. first it turned into a "sni only" settings bit, and now (based on use case) an explicit declarative opt-in. to me - that feels right.
> 
> I view this as declarative - if your configuration changes GOAWAY or Alt-Svc are probably better ways to manage it. I spitballed that we should only allow 1 ORIGIN frame, but that basically isn't plausible due to size limitations, I don't really expect it to be used to dribble updates over time. (but normatively enforcing that would require some kind of CONTINUATION world I hope nobody wants to entertain.)

I'm fine with this alternate way of handling changes. GOAWAY will probably be my choice, avoiding complexity.

Will track my implementation efforts here (https://github.com/icing/mod_h2/issues/96) for anyone interested or wanting to give feedback.

Cheers, Stefan

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Feb 2017 16:25:18 +1100

After discussion and some more edits, it *seems* like people like this direction, so I'm going to merge the pull and issue another draft, so that a wider audience can have a look. Consider the next draft an editors' proposal for what I think can gain consensus.

Cheers,

> On 1 Feb 2017, at 5:50 pm, Mark Nottingham <[email-masked]> wrote:
> 
> [ editor hat ]
> 
> After talking to a few people, I have a few suggested changes in a pull request:
>  https://github.com/httpwg/http-extensions/pull/285/files
> 
> Basically, this:
> I suspect some adjustments will need to be made, but I wanted to get some feedback on the ideas first.
>

---

From: Frederik Deweerdt <[email-masked]>
Date: Tue, 14 Feb 2017 17:50:01 -0800

Hello,

The implementation for H2O is being worked on here:
https://github.com/h2o/h2o/pull/1199. It's in a state that might be useful
for integration testing.

Frederik

On Sun, Feb 12, 2017 at 9:25 PM, Mark Nottingham <[email-masked]> wrote:

> After discussion and some more edits, it *seems* like people like this
> direction, so I'm going to merge the pull and issue another draft, so that
> a wider audience can have a look. Consider the next draft an editors'
> proposal for what I think can gain consensus.
>
> Cheers,
>
>
> >  - Removes the requirement for a supporting client to check DNS to
> determine if the server is authoritative, when ORIGIN is received
> > 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.
> >
> > Cheers,
> >
> > --