Subject: Working Group Last Call The ORIGIN HTTP/2 Frame

From: Patrick McManus <[email-masked]>
Date: Tue, 12 Sep 2017 14:33:32 -0400

Gentlefolk of HTTPbis,

The authors and myself (as chair) have decided that
https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/ (-04) is
ready for the working group last call. Please review it and raise any
issues on the list over the next two weeks. The most recent changes are
focused in the security considerations. There are currently no open issues
in the github tracker.
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-digest/>
WGLC will end on October 01, 2017.

Thanks
-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Sep 2017 11:12:50 +1000

I've read this again.

This is basically done.  I have some pretty minor comments, and some
editorial nits, some of which will appear as a PR shortly.

Minor things:

Section 1.  I think that the last paragraph needs another sentence to
capture the general gist of the recent changes.  Rather than flat out
removing the requirement to check DNS, the document describes the
conditions under which that requirement is removed, and some advice on
when that might be appropriate.

Section 2.2.  The text on flags and forward/backward compatibility
offers no clue about how contention over these bits is managed.  I
would suggest a IETF consensus RFC is the only thing that can define
new flags, but that's just the third thing I thought of.

Section 4.

   The Origin Set's size is unbounded by this specification, and thus
   could be used by attackers to exhaust client resources.  To mitigate
   this risk, clients can monitor their state commitment and close the
   connection if it is too high.

A client could also start forgetting origins that it hasn't used.
There is no demonstrable harm in that and an LRU is less disruptive to
all involved.

Nits:

Section 2.1.  The sentence ending "contains zero to many
Origin-Entry." reads poorly.  Maybe some extra words will fix this.

Section 2.3.  In the note "the initial origin set Section 2.3"
probably needs parentheses around the reference.

Section 2.4.  s/[RFC7540] Section 9.1.1/[RFC7540], Section 9.1.1/ -
twice: note comma; and the same for the 5280 reference

Section 2.4.

   Furthermore, [RFC7540] Section 9.1.1 explicitly allows a connection
   to be used for more than one origin server, if it is authoritative.
   This affects what requests can be sent on the connection, both in
   HEADERS frame by the client and as PUSH_PROMISE frames from the
   server ([RFC7540], Section 8.2.2).

This isn't really perfectly accurate.  It's not awful, but the last
sentence implies that the request is what is important, but I think
that we should concentrate more on the response.  That is, authority
determines the identity of the origin server (or servers) for which
the client will accept responses.  This limits what origins it should
send requests for, and what origins it should accept server pushes
from.

Note to chairs: you may need to find another shepherd for this document.

On Wed, Sep 13, 2017 at 4:33 AM, Patrick McManus <[email-masked]> wrote:
> ready for the working group last call. Please review it and raise any issues
> on the list over the next two weeks. The most recent changes are focused in
> the security considerations. There are currently no open issues in the
> github tracker.
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Sep 2017 13:58:00 +1000

> On 22 Sep 2017, at 11:12 am, Martin Thomson <[email-masked]> wrote:
> 
> I've read this again.
> 

Something like:

This specification relaxes the requirement to check DNS when the ORIGIN frame is in use, provided that other assurances about the server's authority are obtained.

?

> Section 2.2.  The text on flags and forward/backward compatibility offers no clue about how contention over these bits is managed.  I would suggest a IETF consensus RFC is the only thing that can define new flags, but that's just the third thing I thought of.

That's the intent of "future updates to this specification" -- will spell it out.

> There is no demonstrable harm in that and an LRU is less disruptive to

What do people think here? Is a LRU going to cause problems with the server having even less information about what the client considers the connection authoritative for?

Also, should we identify an error code to use in this situation?

> Origin-Entry." reads poorly.  Maybe some extra words will fix this.

Suggest some?

> probably needs parentheses around the reference.

Your pull took care of this, thanks.

> twice: note comma; and the same for the 5280 reference

I believe your pull took care of this too. Well, almost all of it.

> send requests for, and what origins it should accept server pushes

Trying:

This affects what responses can be considered
authoritative, both in HEADERS and PUSH_PROMISE frames from the server ({{!RFC7540}}, Section
8.2.2). Indirectly, it also affects what requests will be sent on a connection, since clients will
generally only send requests on connections that they believe to be authoritative for the origin in
question.

> Note to chairs: you may need to find another shepherd for this document.

Noted.

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Sep 2017 14:23:00 +0200

On 2017-09-22 03:12, Martin Thomson wrote:
> ...
> ...

There were more of these, also sometimes "Section x of [RFCYYYY]" is 
preferable. See <https://github.com/httpwg/http-extensions/pull/404>.

 > ...

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Sep 2017 22:42:48 +1000

> This specification relaxes the requirement to check DNS when the ORIGIN frame is in use, provided that other assurances about the server's authority are obtained.

That is good.

> Also, should we identify an error code to use in this situation?

For the client to use in response to cancelling a push?  Maybe we
needed one of those anyway.  This might not be the right time or place
to add that.  I could write a draft...

>> Origin-Entry." reads poorly.  Maybe some extra words will fix this.

"contains zero or more instances of the Origin-Entry field." perhaps.

> generally only send requests on connections that they believe to be authoritative for the origin in

Good, except that PUSH_PROMISE never includes a response or even part thereof:

"...authoritative, both for responses to requests made by the client
and for server push (see {{!RFC7540}}, Section 8.2.2)."  Or something
like that.

---

From: Mike Bishop <[email-masked]>
Date: Fri, 22 Sep 2017 21:59:50 +0000

I’ve already participated in the DNS-skipping discussion, which I think is the thorniest issue here, so my remaining feedback is reasonably contained.

  *   I’ll second the parallel fork’s suggestion to change “zero to many” => “zero or more”.
  *   I’m a little surprised that the value before receiving an ORIGIN frame isn’t the set of origins in the certificate.  If the behavior is expected to be different in some manner for an uninitialized set, we should specify that case.  If not, why not simplify the logic by initializing the set?
  *   The initialization on receipt of the first ORIGIN frame having the wrong port in the case of Alt-Svc feels a bit weird.  Given that this is an H2 extension, and H2 includes the port in the :authority pseudo-header, why is this not initialized to the authority (including port) of the origin for which the connection was generated?  Otherwise, we wind up considering the server authoritative for an origin for which the server has never claimed to be authoritative.  While I can’t think of an obvious attack, this feels like an opening that’s asking to be exploited some day.
  *   Section 4 contains two nearly-identical paragraphs that probably should be merged and duplicative text trimmed.
  *   Each version of that paragraph contains an OUGHT TO which needs to be capitalized, and the appropriate RFC 6919 reference text added to Section 1.1.  😉

________________________________
From: Patrick McManus [mailto:[email-masked]]
Sent: Tuesday, September 12, 2017 11:34 AM
To: HTTP Working Group <[email-masked]>; mnot <[email-masked]>; Erik Nygren <[email-masked]>
Subject: Working Group Last Call The ORIGIN HTTP/2 Frame

Gentlefolk of HTTPbis,

The authors and myself (as chair) have decided that https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-httpbis-origin-frame%2F&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C4d24e81d80ad4d1a0cb708d4fa0d3999%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408382312405354&sdata=sjQ8gZAWjWPL1B6vCNJDzdU3TW%2BNWrNSLieeceQysaY%3D&reserved=0> (-04) is ready for the working group last call. Please review it and raise any issues on the list over the next two weeks. The most recent changes are focused in the security considerations. There are currently no open issues in the github tracker.

Thanks
-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Sat, 23 Sep 2017 16:43:25 +1000

On Sat, Sep 23, 2017 at 7:59 AM, Mike Bishop <[email-masked]>
wrote:

> I’m a little surprised that the value before receiving an ORIGIN frame
> isn’t the set of origins in the certificate.  If the behavior is expected
> to be different in some manner for an uninitialized set, we should specify
> that case.  If not, why not simplify the logic by initializing the set?
>

This is a backwards compatibility thing.  A server that doesn't advertise
ORIGIN doesn't support it, and is therefore only subject to the rules in
h2.  Which allow coalescing.  Local policy at the client might choose to
ignore this detail, of course.

>
>    - The initialization on receipt of the first ORIGIN frame having the
>    wrong port in the case of Alt-Svc feels a bit weird.  Given that this is an
>    H2 extension, and H2 includes the port in the :authority pseudo-header, why
>    is this not initialized to the authority (including port) of the origin for
>    which the connection was generated?  Otherwise, we wind up considering the
>    server authoritative for an origin for which the server has never claimed
>    to be authoritative.  While I can’t think of an obvious attack, this feels
>    like an opening that’s asking to be exploited some day.
>
> Same as above.  If you connect without seeing ORIGIN, you will assume that
the server is OK.  However, once it is connected, we want to start from a
minimal set and that has to be something that both client and server can
easily agree on.

---

From: Bence Béky <[email-masked]>
Date: Mon, 25 Sep 2017 09:00:18 -0400

Hi,

(from the correct e-mail address this time, sorry to cc'd folks for
duplicate e-mails)

On Sat, Sep 23, 2017 at 2:43 AM, Martin Thomson
<[email-masked]> wrote:
>> isn’t the set of origins in the certificate.  If the behavior is expected to
>> be different in some manner for an uninitialized set, we should specify that
>> case.  If not, why not simplify the logic by initializing the set?
>
>
> ORIGIN doesn't support it, and is therefore only subject to the rules in h2.
> Which allow coalescing.  Local policy at the client might choose to ignore
> this detail, of course.
>

My understanding is that the behavior dictated by RFC7540 rules is
almost the same as the one prescribed by an Origin Set initialized to
the set of origins in the certificate (MUST NOT reuse connection if
the origin is not in the set, MAY reuse if it is according to RFC7540
and SHOULD according to ORIGIN specification with the client having
quite some discretion according to both specs).  Not sure if backwards
compatibility would suffer significantly.

In any case, if the origin set is uninitialized, then the penultimate
paragraph of Section 2.4 should probably specify what proper subset
means in that case.  Is the uninitialized set considered to be the set
of origins in the certificate for the purposes of that paragraph?  Or
is a connection without an initialized Origin Set not covered by this
paragraph?

Cheers,

Bence

---

From: Mike Bishop <[email-masked]>
Date: Mon, 25 Sep 2017 16:51:09 +0000

You do run into a potential loop with that, interestingly.  If the uninitialized state is the set of origins in the certificate, but the server has used ORIGIN to reduce the number of origins for which it will use this connection, then a connection on which you've received an ORIGIN frame would always be a proper subset of a connection on which you haven't (yet, presumably).  This could lead to some interesting behaviors for clients which open multiple connections in parallel for various purposes, if done naively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bence Béky
Sent: Monday, September 25, 2017 6:00 AM
To: Martin Thomson <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Patrick McManus <[email-masked]>; HTTP Working Group <[email-masked]>; mnot <[email-masked]>; Erik Nygren <[email-masked]>
Subject: Re: Working Group Last Call The ORIGIN HTTP/2 Frame

Hi,

(from the correct e-mail address this time, sorry to cc'd folks for duplicate e-mails)

On Sat, Sep 23, 2017 at 2:43 AM, Martin Thomson <[email-masked]> wrote:
>> I’m a little surprised that the value before receiving an ORIGIN 
>> frame isn’t the set of origins in the certificate.  If the behavior 
>> is expected to be different in some manner for an uninitialized set, 
>> we should specify that case.  If not, why not simplify the logic by initializing the set?
>
>
> This is a backwards compatibility thing.  A server that doesn't 
> advertise ORIGIN doesn't support it, and is therefore only subject to the rules in h2.
> Which allow coalescing.  Local policy at the client might choose to 

My understanding is that the behavior dictated by RFC7540 rules is almost the same as the one prescribed by an Origin Set initialized to the set of origins in the certificate (MUST NOT reuse connection if the origin is not in the set, MAY reuse if it is according to RFC7540 and SHOULD according to ORIGIN specification with the client having quite some discretion according to both specs).  Not sure if backwards compatibility would suffer significantly.

In any case, if the origin set is uninitialized, then the penultimate paragraph of Section 2.4 should probably specify what proper subset means in that case.  Is the uninitialized set considered to be the set of origins in the certificate for the purposes of that paragraph?  Or is a connection without an initialized Origin Set not covered by this paragraph?

Cheers,

Bence

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 07:44:35 +1000

> You do run into a potential loop with that, interestingly.  If the uninitialized state is the set of origins in the certificate, but the server has used ORIGIN to reduce the number of origins for w…

Right, there is a race.  Between the time that the handshake completes
and the time that ORIGIN is received, the connection could be marked
as usable for a set of origins.  A client might decide at that point
to abandon connection attempts to those origins, or to start using the
connection for requests to those origins.

Either action results in delays as connections have to be
re-established or requests retried.  Clients might avoid this by
waiting for the first response on a connection before coalescing (on
the principle that ORIGIN is always sent before the first HEADERS
frame).

Should we codify that advice?

---

From: Mike Bishop <[email-masked]>
Date: Mon, 25 Sep 2017 22:02:12 +0000

Presumably you opened the connection because you have requests to make for the origin in SNI; send those immediately.  Of course, you might have expected to coalesce based on history/certificate, and that's reasonable to attempt.  I think I'd mostly say that connections on which an ORIGIN frame hasn't been received aren't considered in the "proper subset" check.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, September 25, 2017 2:45 PM
To: Mike Bishop <[email-masked]>
Cc: Bence Béky <[email-masked]>; Patrick McManus <[email-masked]>; HTTP Working Group <[email-masked]>; mnot <[email-masked]>; Erik Nygren <[email-masked]>
Subject: Re: Working Group Last Call The ORIGIN HTTP/2 Frame

> You do run into a potential loop with that, interestingly.  If the uninitialized state is the set of origins in the certificate, but the server has used ORIGIN to reduce the number of origins for w…

Right, there is a race.  Between the time that the handshake completes and the time that ORIGIN is received, the connection could be marked as usable for a set of origins.  A client might decide at that point to abandon connection attempts to those origins, or to start using the connection for requests to those origins.

Either action results in delays as connections have to be re-established or requests retried.  Clients might avoid this by waiting for the first response on a connection before coalescing (on the principle that ORIGIN is always sent before the first HEADERS frame).

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 09:27:24 +1000

On Tue, Sep 26, 2017 at 8:02 AM, Mike Bishop
<[email-masked]> wrote:
> Presumably you opened the connection because you have requests to make for the origin in SNI; send those immediately.  Of course, you might have expected to coalesce based on history/certificate, and that's reasonable to attempt.

Well, I'm mostly thinking about the time after the TLS connection is
established and before you get ORIGIN.  You don't need to do any
guessing or prediction for that to work.

> I think I'd mostly say that connections on which an ORIGIN frame hasn't been received aren't considered in the "proper subset" check.

Are you suggesting that you don't coalesce if you don't see ORIGIN?
Not sure that I follow.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 25 Sep 2017 23:50:18 +0000

I'm suggesting that you don't close ORIGIN-using connections if they appear to be proper subsets of non-ORIGIN-using connections.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, September 25, 2017 4:27 PM
To: Mike Bishop <[email-masked]>
Cc: Bence Béky <[email-masked]>; Patrick McManus <[email-masked]>; HTTP Working Group <[email-masked]>; mnot <[email-masked]>; Erik Nygren <[email-masked]>
Subject: Re: Working Group Last Call The ORIGIN HTTP/2 Frame

> Presumably you opened the connection because you have requests to make for the origin in SNI; send those immediately.  Of course, you might have expected to coalesce based on history/certificate, a…

Well, I'm mostly thinking about the time after the TLS connection is established and before you get ORIGIN.  You don't need to do any guessing or prediction for that to work.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 09:59:15 +1000

> I'm suggesting that you don't close ORIGIN-using connections if they appear to be proper subsets of non-ORIGIN-using connections.

Ah.  Sure.  It's a stronger signal, so I agree.  If you connect to
api.example.com and get ORIGIN, the fact that your connection to
www.example.com has a wildcard for *.example.com shouldn't cause you
to drop a perfectly good connection.  That is something we should
write down, maybe with a SHOULD on it.

I was more concerned about what you do with non-ORIGIN-using
connection here (which might only be a transient state).  I think that
we should also write down that ORIGIN SHOULD be sent before any
responses and that once responses have been received, the client MAY
assume that the server doesn't support ORIGIN.

Is that a fair assessment of where we are at?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Sep 2017 12:09:45 +1000

> On 23 Sep 2017, at 7:59 am, Mike Bishop <[email-masked]> wrote:
> 
> 	• Section 4 contains two nearly-identical paragraphs that probably should be merged and duplicative text trimmed.

The paras in question:

"""
As a result, clients opting not to consult DNS ought to employ some alternative means to increase confidence that the certificate is legitimate. Examples of mechanisms that can give additional confidence in a certificate include checking for a Signed Certificate Timestamp {{?RFC6929}} and performing certificate revocation checks.

Clients opting not to consult DNS ought to do so only if they have a high degree of confidence that the certificate is legitimate. For instance, clients might skip consulting DNS only if they receive proof of inclusion in a Certificate Transparency log {{?RFC6929}} or they have a recent OCSP response {{?RFC6960}} (possibly using the "status_request" TLS extension {{?RFC6066}}) showing that the certificate was not revoked.
"""

This is the result of heavy wordsmithing^H^H^H^H consensus-building, so stepping carefully, a proposal:

"""
As a result, clients opting not to consult DNS ought to employ some alternative means to establish a high degree of confidence that the certificate is legitimate. For example, clients might skip consulting DNS only if they receive proof of inclusion in a Certificate Transparency log {{?RFC6929}} or they have a recent OCSP response {{?RFC6960}} (possibly using the "status_request" TLS extension {{?RFC6066}}) showing that the certificate was not revoked.
"""

Does that work for everyone?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Sep 2017 12:15:30 +1000

On 26 Sep 2017, at 9:59 am, Martin Thomson <[email-masked]> wrote:
> I think that

Are we starting to use a frame for something that would be better expressed as a setting?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 15:11:25 +1000

> Are we starting to use a frame for something that would be better expressed as a setting?

I do try to avoid adding mechanisms, but I think that you are right
here.  An I_WILL_SEND_ORIGIN flag would avoid any messing around.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 15:10:29 +1000

> Does that work for everyone?

I think that you caught the important pieces.  They really did overlap
almost perfectly.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Sep 2017 15:51:32 +0000

An ORIGIN_SUPPORT setting works for me.  If it's unset, the origin set is what's in the cert; if it's set, the origin set is only the origin you opened the connection for (SNI et al.) and the server has to explicitly add anything else.

Which would mean it also functions as a do-not-coalesce setting, if the server sets it and then never sends an ORIGIN frame.  IIRC, some people wanted that model, and now it would exist fairly simply.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, September 25, 2017 10:11 PM
To: Mark Nottingham <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Bence Béky <[email-masked]>; Patrick McManus <[email-masked]>; HTTP Working Group <[email-masked]>; Erik Nygren <[email-masked]>
Subject: Re: Working Group Last Call The ORIGIN HTTP/2 Frame

> Are we starting to use a frame for something that would be better expressed as a setting?

I do try to avoid adding mechanisms, but I think that you are right here.  An I_WILL_SEND_ORIGIN flag would avoid any messing around.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 27 Sep 2017 20:37:10 -0400

so is ORIGIN_SUPPORT the equivalent of sending an empty ORIGIN frame in the
previous draft?

What's the benefit of additional moving pieces? It doesn't close the race
condition as the client doesn't need to wait for settings to start writing
requests..

On Tue, Sep 26, 2017 at 11:51 AM, Mike Bishop <[email-masked]>
wrote:

> An ORIGIN_SUPPORT setting works for me.  If it's unset, the origin set is
> what's in the cert; if it's set, the origin set is only the origin you
> opened the connection for (SNI et al.) and the server has to explicitly add
> anything else.
>
> Which would mean it also functions as a do-not-coalesce setting, if the
> server sets it and then never sends an ORIGIN frame.  IIRC, some people
> wanted that model, and now it would exist fairly simply.
>
> Cc: Mike Bishop <[email-masked]>; Bence Béky <
> [email-masked]>; Patrick McManus <[email-masked]>; HTTP Working
> Group <[email-masked]>; Erik Nygren <[email-masked]>
> I do try to avoid adding mechanisms, but I think that you are right here.
> An I_WILL_SEND_ORIGIN flag would avoid any messing around.
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Sep 2017 10:47:33 +1000

> condition as the client doesn't need to wait for settings to start writing

But the server HAS to send SETTINGS.  So at least the waiting is
deterministic.  And in TLS 1.3, the server speaks first, so there
shouldn't be any waiting around there.  I agree that this is not ideal
for TLS 1.2, but you could simply decide not to wait and suffer the
consequences if you are wrong.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 27 Sep 2017 21:43:21 -0400

On Wed, Sep 27, 2017 at 8:47 PM, Martin Thomson <[email-masked]>
wrote:

> deterministic.

deterministic might be a little strong. The server has to send it as the
first TCP bytes, but it doesn't have to send it right away.. I guess I
could mumble something about congestion controllers that measure in packets
instead of bytes giving a motivation for such behavior. I guess in general
I'm deeply skeptical of any algorithm that expects waiting.

I'm not going to object to the setting - it just seems it doesn't really
address the fact that the client is going to see both 7540 rules and ORIGIN
rules at some point on the same connection so there's not a lot of point to
it imo.

>   And in TLS 1.3, the server speaks first, so there

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Sep 2017 11:48:07 +1000

> rules at some point on the same connection so there's not a lot of point to

I see your point.  It narrows, but doesn't eliminate the window of
uncertainty and as a result it isn't that much use to you.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Sep 2017 12:23:53 +1000

I'm OK either way here; it's attractive to have a deadline for knowing whether the connection is under the ORIGIN model (first SETTINGS), but I'm also a bit nervous about introducing such a big change relatively late in the day.

Put another way - does anyone think that this is clearly better than the current spec and needs to get in?

PR here (still needs some work if we want to adopt):
  https://github.com/httpwg/http-extensions/pull/406

> On 28 Sep 2017, at 11:48 am, Martin Thomson <[email-masked]> wrote:
>

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 28 Sep 2017 11:26:04 +0000

Right now the server has no way of knowing whether the client supports
ORIGIN or not. Would a client-sent ORIGIN_SUPPORT frame be a good way for
servers to decide whether or not to send ORIGIN frames (which could be
wasteful if the client doesn't support them)? Or are there downsides to
such a mechanism that I'm forgetting?

Nick

On Thu, Sep 28, 2017 at 3:28 AM Mark Nottingham <[email-masked]> wrote:

> I'm OK either way here; it's attractive to have a deadline for knowing
> whether the connection is under the ORIGIN model (first SETTINGS), but I'm
> also a bit nervous about introducing such a big change relatively late in
> the day.
>

---

From: Patrick McManus <[email-masked]>
Date: Thu, 28 Sep 2017 11:00:12 -0400

this is really the kind of thing quic should figure out how to put in
transport parameters; I don't think we want to encourage waiting before
sending origin info. It's definitely a bw for latency trade tho.