Subject: draft-nottingham-httpbis-origin-frame

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Mar 2016 13:40:12 -0400

I support draft-nottingham-httpbis-origin-frame for wg adoption, if it were
to be put forward.

I think it is a little unclear on whether or not it intends to include the
use case of advertising origins that are covered by the traditional notion
of authoritative (i.e. certificate checks, key pin, et al) but not
necessarily overlapping DNS. I guess, upon reading, that it doesn't mean to
include that - but I think it should.

The DNS restriction of 7540 is really about sane routing of requests to the
right server by getting an opt-in that indicates configuration. Its not
really about security - DNS is not really part of the security model.

Its a reasonable bootstrap, but DNS is rather imperfect for this signal; as
much as we like to imagine a single and consistent DNS space that's not the
way it translates in practice. Concerns over load balancing are just one of
many reasons why a strict application of 7540 might not allow for
coalescing where it was actually setup and desired. This seems as likely as
the 421 case that motivates the draft. Both could be addressed.

The origin frame is a place to put a strong signal that this established
connection is suitable for the following set of origins no matter what the
clients view of the DNS. (subject to certificate rules, of course). Indeed
it would have the interesting property of removing the need to resolve DNS
for the client for matching origins which is a definite additional
performance win too even in cases where the DNS does overlap.

Plausibly these extension frames could get fairly big. It would seem easy
enough to define them as optionally compressed (with the header compression
state) in the presence of a settings ack of the extension (and a flag bit).

As an aside, it probably makes sense at this time (different document) to
add (back) the extension for including more certs serialized into the
connection to allow more origins to be advertised.

If there is interest, I'd be happy to work on those 3 points.

-Patrick

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 Mar 2016 17:59:15 +0000

On the last point, I direct your attention to https://github.com/MikeBishop/http2-client-certs/blob/additional_certs/draft-bishop-http2-additional-certs.md -- not currently submitted, but a one-off exploration of using the same frames from Martin's and my client cert draft to send additional certs on the server as well. I'd prefer to focus on the client-to-server direction first, but there is no technical reason the frames can't do the same thing in the opposite direction.

From: Patrick McManus [mailto:[email-masked]]
Sent: Monday, March 14, 2016 10:40 AM
To: HTTP Working Group <[email-masked]>
Subject: draft-nottingham-httpbis-origin-frame

I support draft-nottingham-httpbis-origin-frame for wg adoption, if it were to be put forward.
I think it is a little unclear on whether or not it intends to include the use case of advertising origins that are covered by the traditional notion of authoritative (i.e. certificate checks, key pin, et al) but not necessarily overlapping DNS. I guess, upon reading, that it doesn't mean to include that - but I think it should.
The DNS restriction of 7540 is really about sane routing of requests to the right server by getting an opt-in that indicates configuration. Its not really about security - DNS is not really part of the security model.
Its a reasonable bootstrap, but DNS is rather imperfect for this signal; as much as we like to imagine a single and consistent DNS space that's not the way it translates in practice. Concerns over load balancing are just one of many reasons why a strict application of 7540 might not allow for coalescing where it was actually setup and desired. This seems as likely as the 421 case that motivates the draft. Both could be addressed.

The origin frame is a place to put a strong signal that this established connection is suitable for the following set of origins no matter what the clients view of the DNS. (subject to certificate rules, of course). Indeed it would have the interesting property of removing the need to resolve DNS for the client for matching origins which is a definite additional performance win too even in cases where the DNS does overlap.
Plausibly these extension frames could get fairly big. It would seem easy enough to define them as optionally compressed (with the header compression state) in the presence of a settings ack of the extension (and a flag bit).

As an aside, it probably makes sense at this time (different document) to add (back) the extension for including more certs serialized into the connection to allow more origins to be advertised.
If there is interest, I'd be happy to work on those 3 points.

-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Mar 2016 09:59:59 +1100

> really about security - DNS is not really part of the security model.

I 99% agree.  The other 1% is reserved for a minor concern about the
way the security model interacts with the rest of the system.

When a URL becomes known to a client, it then seeks out a server that
can serve that authority.  RFC 7540 didn't fundamentally change that
by allowing coalescing: the same process was followed, we just allowed
certain steps to be merged with work already done.

However, this would skip the DNS step entirely.  That's not bad,
because we don't rely on it for any sort of security property.
However... it does allow for some interesting capture scenarios.

For example, if I were able to steal a certificate for a few
interesting names, I would only have to capture a connection toward a
single one of those names in order to effectively intercept all
requests to those names.  With Alt-Svc, I would be able to continue
that capture as long as the theft remained viable.  With Mike's
additional certs, it's possible to use different stolen certificates.

It's a small concern, because I think that the risk is small in
comparison to the potential gain, but I don't think that this is
something that we can reasonably ignore.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 Mar 2016 23:15:44 +0000

I'm hesitant to drop DNS altogether. It's not quite part of the security model, but it kind of is. By requiring DNS to match, an attacker has to subvert either DNS or IP routing. My draft was targeting the case where the server has the same IP address, but multiple certificates. (Of course, if you're trying to support non-SNI clients….) I still prefer Alt-Svc to provide a link from the original origin to the endpoint claiming to have the certs.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, March 14, 2016 4:00 PM
To: Patrick McManus <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: draft-nottingham-httpbis-origin-frame

On 15 March 2016 at 04:40, Patrick McManus <[email-masked]> wrote:
> The DNS restriction of 7540 is really about sane routing of requests 
> to the right server by getting an opt-in that indicates configuration. 
> Its not really about security - DNS is not really part of the security model.

I 99% agree.  The other 1% is reserved for a minor concern about the way the security model interacts with the rest of the system.

When a URL becomes known to a client, it then seeks out a server that can serve that authority.  RFC 7540 didn't fundamentally change that by allowing coalescing: the same process was followed, we just allowed certain steps to be merged with work already done.

However, this would skip the DNS step entirely.  That's not bad, because we don't rely on it for any sort of security property.
However... it does allow for some interesting capture scenarios.

For example, if I were able to steal a certificate for a few interesting names, I would only have to capture a connection toward a single one of those names in order to effectively intercept all requests to those names.  With Alt-Svc, I would be able to continue that capture as long as the theft remained viable.  With Mike's additional certs, it's possible to use different stolen certificates.

It's a small concern, because I think that the risk is small in comparison to the potential gain, but I don't think that this is something that we can reasonably ignore.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Mar 2016 10:18:24 +1100

Hi Patrick,

> On 15 Mar 2016, at 4:40 AM, Patrick McManus <[email-masked]> wrote:
> 

OK. I've had it on hold for a while, looking for more interest, so thanks for speaking up. 

I was also holding off because of our workload, but I think we can take on another draft or two. I've already talked to Barry about this one, so I'll do a CfA shortly.

> The origin frame is a place to put a strong signal that this established connection is suitable for the following set of origins no matter what the clients view of the DNS. (subject to certificate…

That seems reasonable (acknowledging Martin's concern there too). I think this is something that's in-scope for discussion if we adopt.

> Plausibly these extension frames could get fairly big. It would seem easy enough to define them as optionally compressed (with the header compression state) in the presence of a settings ack of the…

True, but I'm not sure using the HPACK state would help; straight gzip or similar might be better. Again, something to discuss.

> As an aside, it probably makes sense at this time (different document) to add (back) the extension for including more certs serialized into the connection to allow more origins to be advertised

Yes, that's been something lurking over the horizon for a while. It's good to see Mike's already working on it, and I'd encourage him to submit, so we can track it.

Cheers,

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 15 Mar 2016 20:40:39 +0000

Per Mark's request:

=========
A new version of I-D, draft-bishop-httpbis-http2-additional-certs-00.txt
has been successfully submitted by Mike Bishop and posted to the IETF repository.

Name:		draft-bishop-httpbis-http2-additional-certs
Revision:	00
Title:		Secondary Server-Certificate Authentication in HTTP/2
Document date:	2016-03-15
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additional-certs/
Htmlized:       https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-00

Abstract:
   Many HTTP servers host content from several origins.  HTTP/2
   [RFC7540] permits clients to reuse an existing HTTP connection to a
   server provided that certain conditions are satisfied.  One of these
   conditions is the inclusion of the secondary origin in the
   certificate provided during the TLS [I-D.ietf-tls-tls13] handshake.

   In many cases, origins will wish to maintain separate certificates
   for different origins but still desire the benefits of a shared HTTP
   connection.  This draft describes how frames which were defined to
   transfer client certificates might be used to provide additional
   server certificates as well.
=========

(Please note that this draft is me playing with an idea.  I can't promise implementer interest even from those implementations I work with. This is strictly "bored over Christmas" work product.)

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Monday, March 14, 2016 4:18 PM
To: Patrick McManus <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: draft-nottingham-httpbis-origin-frame

Hi Patrick,

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Mar 2016 10:33:51 +1100

Thanks, Mike. 

I've put that and the "decomposing" draft on the WatchList. Would you like some time to present about them in B-A?

Cheers,

> On 16 Mar 2016, at 7:40 AM, Mike Bishop <[email-masked]> wrote:
> 
> Per Mark's request:
> 
> =========

---

From: Patrick McManus <[email-masked]>
Date: Wed, 16 Mar 2016 14:35:56 -0400

> something that we can reasonably ignore.

[until we adopt a draft this is all just kick-the-ball-around stuff]

fwiw, there is a spectrum of ways to interpret the 7540 rules that a
declarative origin frame could help with. in 7540 coalescing Firefox goes a
little towards the aggressive side in order to enable coalescing on a
couple of content providers that want coalescing but don't always advertise
consistent DNS views. This has caught a couple other providers by surprise
who saw coalescing but did not expect it in an edge case (I get to explain
421 to them :)) - an origin extension that opts in arbitrary origins
provides a more deterministic implementation.

I would want to address the change with strong text to make this clear
(something I think, only in retrospect, that 7540 could have done stronger
around coalescing rules there.) but as a practical matter the internet is
moving away from addressing defining content and this just rides that wave.
and sure, content-centric or named-data networking lies somewhere on that
road. But its too far away to see clearly :)

Names are what identify content and signatures are what makes you believe
it. The notion of DNS resolution and IP routes being directly tied to this
is already long gone and folks depending on that are probably in grave
peril already (i.e. http://). Which is why we already don't rely on it in
https://. And if you are faced with a certificate compromise, relying on
routing to save you is pretty weak solace.

When I click on my search provider button maybe I am routed to
searchProvider's data center.. but maybe I'm routed to a CDN, or maybe
dynamically load shifted to a fail over CDN the way CDNI talks about..
perhaps it changes every 300 seconds. maybe I'm served out of a cache
(perhaps local, perhaps remote) or directed to an alternate service.. maybe
my route is hijacked L4 style by a transparent device that lies about the
addressing. Perhaps I'm behind a nat. Or two. Or three. Or have had my DNS
spoofed via race condition. Or routed via an onion network or plain old
vpn. In all of those cases the decision on whether or not to use the
content is independent of addressing and routing - a declarative origin
frame isn't moving into uncharted territory.

Those addresses and routes are just the ephemeral glue we use to get you to
the content you want - the content doesn't inherently possess addresses or
routes.. if another set of addresses and routes delivers the same
verifiable content in a better way thats a good thing and loosening the
implicit dependence on DNS and IP is also good thing.

-Patrick

---

From: Phil Lello <[email-masked]>
Date: Wed, 16 Mar 2016 19:18:09 +0000

A possibly related edge case worth considering; suppose server1.example.com
is provided by a global CDN, and server2.example.com only exists in NZ, and
the browser is in the UK.

What would be the desired behaviour if the initial connection is made to
server2.example.com (NZ), which advertises it's also an origin for
server1.example.com (which it is, although the closest CDN endpoint to the
browser is in the UK)?

Phil

On Wed, Mar 16, 2016 at 6:35 PM, Patrick McManus <[email-masked]>
wrote:

> Those addresses and routes are just the ephemeral glue we use to get you
> to the content you want - the content doesn't inherently possess addresses
> or routes.. if another set of addresses and routes delivers the same

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 16 Mar 2016 17:45:27 -0700

This is a very powerful idea. I support further work in this direction.

On Tue, Mar 15, 2016 at 1:40 PM, Mike Bishop <[email-masked]>
wrote:

> URL:
> https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additional-certs/
> Htmlized:
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-00
>
>
> Abstract:
> (Please note that this draft is me playing with an idea.  I can't promise
> implementer interest even from those implementations I work with. This is
> strictly "bored over Christmas" work product.)
>
> I was also holding off because of our workload, but I think we can take on
> another draft or two. I've already talked to Barry about this one, so I'll
> do a CfA shortly.
>
>
> > I think it is a little unclear on whether or not it intends to include
> the use case of advertising origins that are covered by the traditional
> notion of authoritative (i.e. certificate checks, key pin, et al) but not
> > The DNS restriction of 7540 is really about sane routing of requests to
> the right server by getting an opt-in that indicates configuration. Its not
> > Its a reasonable bootstrap, but DNS is rather imperfect for this signal;
> as much as we like to imagine a single and consistent DNS space that's not
> the way it translates in practice. Concerns over load balancing are just
> one of many reasons why a strict application of 7540 might not allow for
> That seems reasonable (acknowledging Martin's concern there too). I think
> this is something that's in-scope for discussion if we adopt.
>
>
> > Plausibly these extension frames could get fairly big. It would seem
> easy enough to define them as optionally compressed (with the header
> compression state) in the presence of a settings ack of the extension (and
> a flag bit).
>
> True, but I'm not sure using the HPACK state would help; straight gzip or
> similar might be better. Again, something to discuss.
>
>
> > As an aside, it probably makes sense at this time (different document)
> to add (back) the extension for including more certs serialized into the
> connection to allow more origins to be advertised
>
> Yes, that's been something lurking over the horizon for a while. It's good
> to see Mike's already working on it, and I'd encourage him to submit, so we
> can track it.
>
> Cheers,
>
>
> --

---

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Mar 2016 23:36:24 +0000

I would think that server2, noticing the client’s location, should send both an ORIGIN frame indicating that it can serve content for server1, but also an Alt-Svc frame or header suggesting the use of a specific node closer to the UK.

From: Phil Lello [mailto:[email-masked]]
Sent: Wednesday, March 16, 2016 12:18 PM
To: Patrick McManus <[email-masked]>
Cc: Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: draft-nottingham-httpbis-origin-frame

A possibly related edge case worth considering; suppose server1.example.com<http://server1.example.com> is provided by a global CDN, and server2.example.com<http://server2.example.com> only exists in NZ, and the browser is in the UK.
What would be the desired behaviour if the initial connection is made to server2.example.com<http://server2.example.com> (NZ), which advertises it's also an origin for server1.example.com<http://server1.example.com> (which it is, although the closest CDN endpoint to the browser is in the UK)?
Phil

On Wed, Mar 16, 2016 at 6:35 PM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Mar 14, 2016 at 6:59 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

fwiw, there is a spectrum of ways to interpret the 7540 rules that a declarative origin frame could help with. in 7540 coalescing Firefox goes a little towards the aggressive side in order to enable coalescing on a couple of content providers that want coalescing but don't always advertise consistent DNS views. This has caught a couple other providers by surprise who saw coalescing but did not expect it in an edge case (I get to explain 421 to them :)) - an origin extension that opts in arbitrary origins provides a more deterministic implementation.
I would want to address the change with strong text to make this clear (something I think, only in retrospect, that 7540 could have done stronger around coalescing rules there.) but as a practical matter the internet is moving away from addressing defining content and this just rides that wave. and sure, content-centric or named-data networking lies somewhere on that road. But its too far away to see clearly :)
Names are what identify content and signatures are what makes you believe it. The notion of DNS resolution and IP routes being directly tied to this is already long gone and folks depending on that are probably in grave peril already (i.e. http://). Which is why we already don't rely on it in https://. And if you are faced with a certificate compromise, relying on routing to save you is pretty weak solace.

When I click on my search provider button maybe I am routed to searchProvider's data center.. but maybe I'm routed to a CDN, or maybe dynamically load shifted to a fail over CDN the way CDNI talks about.. perhaps it changes every 300 seconds. maybe I'm served out of a cache (perhaps local, perhaps remote) or directed to an alternate service.. maybe my route is hijacked L4 style by a transparent device that lies about the addressing. Perhaps I'm behind a nat. Or two. Or three. Or have had my DNS spoofed via race condition. Or routed via an onion network or plain old vpn. In all of those cases the decision on whether or not to use the content is independent of addressing and routing - a declarative origin frame isn't moving into uncharted territory.

Those addresses and routes are just the ephemeral glue we use to get you to the content you want - the content doesn't inherently possess addresses or routes.. if another set of addresses and routes delivers the same verifiable content in a better way thats a good thing and loosening the implicit dependence on DNS and IP is also good thing.

-Patrick

---

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Mar 2016 23:50:26 +0000

Thinking about this further, it seems like one way to make this work is presenting a copy of the DNS SEC record. That would mean the server can demonstrate that, somewhere in the DNS, the name in question validly resolves to its IP even if that's not the case from the client's location.  This would be analogous to https://datatracker.ietf.org/doc/draft-shore-tls-dnssec-chain-extension/, in which the server presents the DNS SEC records at the TLS layer which prove the validity of the cert used in the same exchange.

I'm envisioning a scenario where a server possesses many certs, but uses a distinct IP for each cert to cope with non-SNI clients. No client would ever be served any of the other IP is for a given name, but they all reach, if not identical, at least equivalent endpoints. I'm afraid my knowledge of DNSSEC is sufficiently limited that I don't know whether a never-served record can still be signed and validated. Anyone else?

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Monday, March 14, 2016 4:18 PM
To: Patrick McManus <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: draft-nottingham-httpbis-origin-frame

Hi Patrick,

Cheers,

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Mar 2016 11:03:37 +1100

Well, Roberto would say "told you so".  He was pushing the notion of
pushing DNSSEC records in 2011.