Subject: I-D Action: draft-ietf-httpbis-alt-svc-12.txt

From: [email-masked]
Date: Mon, 08 Feb 2016 23:48:51 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol of the IETF.

        Title           : HTTP Alternative Services
        Authors         : Mark Nottingham
                          Patrick McManus
                          Julian F. Reschke
	Filename        : draft-ietf-httpbis-alt-svc-12.txt
	Pages           : 24
	Date            : 2016-02-08

Abstract:
   This document specifies "Alternative Services" for HTTP, which allow
   an origin's resources to be authoritatively available at a separate
   network location, possibly accessed with a different protocol
   configuration.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-alt-svc/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-alt-svc-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Feb 2016 14:31:11 +1100

Hi Kari,

I think Barry is about to start IETF LC on this, so if that happens, we'll just consider this LC feedback.

It's a fair point. This is difficult to specify; one way we could do it is to specify the way we know here (using HTTPS with a strong cert), and require other ways to update this specification (with an Updates: field on the Standards Track).

What do others think?

> On 10 Feb 2016, at 5:28 am, Kari Hurtta <[email-masked]> wrote:
> 
> 
> Tricky
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1
> 
> | 2.1. Host Authentication
> | 
> | 
> |   Clients MUST have reasonable assurances that the alternative service
> |   is under control of and valid for the whole origin.
> 
> I have impression that on absence of other protocol, this is mean to
> forbid use plain HTTP/2 (ie "h2c"), because there is no "reasonable
> assurance".
> 
> But is reader understanding that? There is examples which use "h2c".
> 
> This does not give that
> 
> |                                   However, if "other.example.com" is
> |   offered with the "h2c" protocol, the client cannot use it, because
> |   there is no mechanism in that protocol to establish the relationship
> |   between the origin and the alternative.
> 
> Reader may think that there is "reasonable assurance" when hostname
> is same.
> 
> There is 
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-9.1
> 
> | 9.1. Changing Ports
> | 
> | 
> |   Using an alternative service implies accessing an origin's resources
> |   on an alternative port, at a minimum.  An attacker that can inject
> |   alternative services and listen at the advertised port is therefore
> |   able to hijack an origin.  On certain servers, it is normal for users
> |   to be able to control some personal pages available on a shared port,
> |   and also to accept to requests on less-privileged ports.
> 
> But that part is confusing:
> 
> |   This risk is mitigated by the requirements in Section 2.1.
> 
> When requirement is "reasonable assurance" I think that reader
> is confused.
> 
> "h2c" examples are
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-3
> 
> |   The Alt-Svc field value can have multiple values:
> |   
> |   Alt-Svc: h2c=":8000", h2=":443"
> 
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-3.1
> 
> 
> |     HTTP/1.1 200 OK
> |     Content-Type: text/html
> |     Cache-Control: max-age=600
> |     Age: 30
> |     Alt-Svc: h2c=":8000"; ma=60
> 
> 
> So my question is: Can reader understand this without
> reading https://lists.w3.org/Archives/Public/ietf-http-wg/ ?
> 
> ( Or without reading that other protocol RFC which 
>  gives reasonable assurance. )
> 
> / Kari Hurtta
> 

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Feb 2016 19:30:32 +1100

On 10 February 2016 at 14:31, Mark Nottingham <[email-masked]> wrote:
> This is difficult to specify; one way we could do it is to specify the way we know here (using HTTPS with a strong cert), and require other ways to update this specification (with an Updates: field on the Standards Track).

This seems reasonable.  If h2c starts to see wider deployment, then a
good definition for that that assurance might look like will have to
emerge (or alt-svc won't be used there).

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 09 Feb 2016 18:29:03 +0000

Tricky

This does not give that

There is 

| 9.1. Changing Ports
| 
| 

"h2c" examples are

|     HTTP/1.1 200 OK

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 10 Feb 2016 04:38:25 +0000

Mark Nottingham <[email-masked]>: (Wed Feb 10 05:31:11 2016)
> I think Barry is about to start IETF LC on this, so if that happens, we'll just consider this LC feedback.

I see.

=>

|                                    However, if "other.example.com" 
|   (or "www.example.com" on another port) is offered with the "h2c" protocol, 
|   the client cannot use it, because there is no mechanism in that protocol 
|   to establish the relationship between the origin and the alternative.

I think that this addition gives enough hint about that.

And probably drop "h2c" examples or add note (to near of examples):

| "h2c" protocol on example assumes that "reasonable assurance" (Section 2.1)
| is established elsewhere.

Or something like that.

/ Kari Hurtta

---

From: Mike Bishop <[email-masked]>
Date: Wed, 10 Feb 2016 21:31:26 +0000

I agree.  For example, if the proposal of using a .well-known URI to delegate to an Alt-Svc gets traction and becomes an RFC, it could just update Alt-Svc to define that as having assurance as well.

Note that h2c on the same port doesn't need Alt-Svc, since the Upgrade: header from the server is already defined.  So what we're really talking about is h2c *on a different port*.  Honestly, I think if we put it on a different port and publish an Alt-Svc pointing to it, we might as well go direct (i.e. don't Upgrade from HTTP/1.1 on the new connection), which would need a new token anyway.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2016 12:31 AM
To: Mark Nottingham <[email-masked]>
Cc: Kari Hurtta <[email-masked]>; HTTP WG <[email-masked]>; Patrick McManus <[email-masked]>; Julian F. Reschke <[email-masked]>
Subject: Re: draft-ietf-httpbis-alt-svc-12.txt

> This is difficult to specify; one way we could do it is to specify the way we know here (using HTTPS with a strong cert), and require other ways to update this specification (with an Updates: field…

This seems reasonable.  If h2c starts to see wider deployment, then a good definition for that that assurance might look like will have to emerge (or alt-svc won't be used there).

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Feb 2016 22:48:05 -0500

> just consider this LC feedback.

And so it was started, and so you should consider it.

Barry

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 11 Feb 2016 17:22:14 +1300

On 11/02/2016 10:31 a.m., Mike Bishop wrote:
> I agree.  For example, if the proposal of using a .well-known URI to
> delegate to an Alt-Svc gets traction and becomes an RFC, it could
> just update Alt-Svc to define that as having assurance as well.
> 
> Note that h2c on the same port doesn't need Alt-Svc, since the
> Upgrade: header from the server is already defined.  So what we're
> really talking about is h2c *on a different port*.  Honestly, I think
> if we put it on a different port and publish an Alt-Svc pointing to
> it, we might as well go direct (i.e. don't Upgrade from HTTP/1.1 on
> the new connection), which would need a new token anyway.

Isn't that the point of Alt-Svc though? to have *both* servers able to
deliver the resource, and to inform client of the non-usual alternative
rather than the normal server always 302 redirecting.

Amos

---

From: Mike Bishop <[email-masked]>
Date: Thu, 11 Feb 2016 05:11:51 +0000

I think we're talking about two different scenarios.  I'm referring to same host + different port, which used to be allowed without TLS.  Allowing another host to serve the resource has (always?) required TLS, which means h2c just isn't a valid token for that scenario.

-----Original Message-----
From: Amos Jeffries [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2016 8:22 PM
To: [email-masked]
Subject: Re: draft-ietf-httpbis-alt-svc-12.txt

On 11/02/2016 10:31 a.m., Mike Bishop wrote:
> delegate to an Alt-Svc gets traction and becomes an RFC, it could just 
> update Alt-Svc to define that as having assurance as well.
> 

Isn't that the point of Alt-Svc though? to have *both* servers able to deliver the resource, and to inform client of the non-usual alternative rather than the normal server always 302 redirecting.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Feb 2016 13:16:09 +1100

I've created
  https://github.com/httpwg/http-extensions/issues/148
to track this.

I think removing h2c from the examples and clarifying the example as Kari explained (1 and 2 in the issue) are not controversial (verging on editorial).

The remaining question (3 in the issue) is whether we should firm up the definition of "reasonable assurances" to require another way of achieving that to be documented in an RFC that updates this one.

Mike B has already supported this approach; what do others think? 

> On 11 Feb 2016, at 2:48 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Feb 2016 18:37:26 -0800

> Mike B has already supported this approach; what do others think?

I think that it's a fine approach.

Are we simply going to reference RFC 2818 in defining "reasonable
assurances"?  Maybe with a "Assurances that are considered reasonable
might include the certificate checks defined in RFC 2818, though
additional or alternative checks might be used by clients."

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Feb 2016 13:40:50 +1100

> On 20 Feb 2016, at 1:37 PM, Martin Thomson <[email-masked]> wrote:
> 

I think so, although with language stronger than "might include"; e.g.,

"For the purposes of this document, "reasonable assurances" can be established through use of a TLS-based protocol with the certificate checks defined in RFC2818. Other means of establishing them MUST be documented in an RFC that updates this specification. Clients MAY impose additional criteria for establishing reasonable assurances."

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Feb 2016 18:44:32 -0800

> "For the purposes of this document, "reasonable assurances" can be established through use of a TLS-based protocol with the certificate checks defined in RFC2818. Other means of establishing them M…

That looks good.  I don't think that it helps to note that in practice
"MAY" becomes "will".

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Feb 2016 14:18:55 +0100

> Note that h2c on the same port doesn't need Alt-Svc, since the Upgrade: header from the server is already defined.  So what we're really talking about is h2c *on a different port*.  Honestly, I thi…

"new token" in what sense?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 26 Feb 2016 11:56:03 +1100

I've taken a stab at this:
  https://github.com/httpwg/http-extensions/commit/f1024d233157e

Please review.

Cheers,

> On 20 Feb 2016, at 1:44 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Feb 2016 08:26:41 +0100

That says:

>    For the purposes of this document, "reasonable assurances" can be
>    established through use of a TLS-based protocol with the certificate
>    checks defined in [RFC2818].  Other means of establishing them MUST
>    be documented in an RFC that updates this specification.  Clients MAY
>    impose additional criteria for establishing reasonable assurances.

As far as I understand, this is a hook for 
draft-ietf-httpbis-http2-encryption-03, which is currently labeled 
"experimental". It is my understanding that experimental RFCs will have 
a hard time "updating" a standards-track RFC, though...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 26 Feb 2016 18:29:48 +1100

> On 26 Feb 2016, at 6:26 PM, Julian Reschke <[email-masked]> wrote:
> 
> As far as I understand, this is a hook for draft-ietf-httpbis-http2-encryption-03, which is currently labeled "experimental". It is my understanding that experimental RFCs will have a hard time "updating" a standards-track RFC, though...

Barry, any insights here?

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 26 Feb 2016 08:22:41 +0000

Kari Hurtta <[email-masked]>: (Fri Feb 26 09:18:15 2016)
> Julian Reschke <[email-masked]>: (Thu Feb 25 15:18:55 2016)
> Hypertext Transfer Protocol Version 2 (HTTP/2)
> RFC 7540
> 
> 3.1.  HTTP/2 Version Identification
> https://tools.ietf.org/html/rfc7540#section-3.1
> 
> |   o  The string "h2c" identifies the protocol where HTTP/2 is run over
> |      cleartext TCP.  This identifier is used in the HTTP/1.1 Upgrade
> |      header field and in any place where HTTP/2 over TCP is identified.
> |
> |      The "h2c" string is reserved from the ALPN identifier space but
> |      describes a protocol that does not use TLS. 
> 
> 
> Is "h2c" reserved for clear text HTTP/2 with Upgrade: -header negotiation ?
> 
> If there is "h2c" on Alt-Svc it can mean either clear text HTTP/2
> with Upgrade -negation or clear text HTTP/2 with Prior Knowledge
> but it can not mean both.
> 
> 3.4.  Starting HTTP/2 with Prior Knowledge
> https://tools.ietf.org/html/rfc7540#section-3.4
> 
> |   A client can learn that a particular server supports HTTP/2 by other
> |   means.  For example, [ALT-SVC] describes a mechanism for advertising
> |   this capability.
> 
> So it is unclear that is Upgrade: -supposed to be run when 
> Alt-Svc -header gives "h2c". But clear text HTTP/2 usage with 
> Alt-Svc -header needs own RFC anyway (and nobody supports clear 
> text HTTP/2).

https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-alt-svc.xml

Also this implicates that "h2c" means Upgrade: -usage:

| <t>
|    Furthermore, if the connection to the alternative service fails or is unresponsive, the client
|    &MAY; fall back to using the origin or another alternative service. Note, however, that this
|   could be the basis of a downgrade attack, thus losing any enhanced security properties of the
|   alternative service.  If the connection to the alternative service does not negotiate the
|   expected protocol (for example, ALPN fails to negotiate h2, or an Upgrade request to h2c is
|   not accepted), the connection to the alternative service &MUST; be considered to have failed.
| </t>

But because "h2c" with Alt-Svc needs new "reasonable assurances"
this can wait that someone wants write specification for this.

/ kari Hurtta

---

From: Barry Leiba <[email-masked]>
Date: Fri, 26 Feb 2016 09:37:10 -0500

>> As far as I understand, this is a hook for draft-ietf-httpbis-http2-encryption-03,
>> which is currently labeled "experimental". It is my understanding that
>> experimental RFCs will have a hard time "updating" a standards-track
>> RFC, though...
>

Yeh, why is "that updates this document" there?  Why do readers of
this document have to know about means that are provided in other
documents, such that "updates" is needed?

Barry

---

From: Martin Thomson <[email-masked]>
Date: Sat, 27 Feb 2016 07:42:33 +1100

We should be clear, 3.4 (prior knowledge) is exceptional and doesn't apply
here.  That same prior knowledge could be used to find an alternative.
On Feb 26, 2016 6:18 PM, "Kari Hurtta" <[email-masked]> wrote:

> >> Note that h2c on the same port doesn't need Alt-Svc, since the Upgrade:
> header from the server is already defined.  So what we're really talking
> about is h2c *on a different port*.  Honestly, I think if we put it on a
> different port and publish an Alt-Svc pointing to it, we might as well go
> direct (i.e. don't Upgrade from HTTP/1.1 on the new connection), which
> would need a new token anyway.
> >

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 26 Feb 2016 12:59:55 -0800

> On Feb 19, 2016, at 6:16 PM, Mark Nottingham <[email-masked]> wrote:
> 
> I've created

FWIW, I think the entire section is nonsense.  Having the same https certificate
doesn't say anything about how many different authorities might be present on
a single server.  It only says the domain name is owned by the certificate holder.
There is no way for a client to know whether that means the alternative service
is valid for the whole origin or just a single resource within that origin.

Likewise, changing the port number means the destination is a different authority.
It may have the same owner, but it is still a different authority.

As such, I don't see how this section does anything to mitigate the attacks
described in changing-ports and host_security.  It certainly doesn't protect
against MITM attacks resulting in a persistent redirection.

I think it would be better to make more explicit requirements in the main section
that define the protocol and to ensure that the requirements are properly targeted
to specific types of implementations (like we did for RFC7230). Furthermore,
differentiate the requirements based on the nature of the original connection:

   If the original connection is not secured to a specific authority (e.g.,
   TLS was not negotiated and a secure connection established prior to receipt
   of the Alt-Svc header field), then

     [require that the alternative service use TLS (or equivalent) and provide
      a certificate valid for the original host]

     [explain that the (many) potential attacks are no worse than
      the existing lack of content and header field integrity]

   Otherwise,

     [do more, like require that the certificate used in the original connection
      be identical to that used by the alternative service, since anything less
      allows the authority to persist longer than the original cert validity.
      Yes, this requires caching the cert id along with the persisted alt-svc.]

     [explain that this limits potential attacks to what is already possible
      as within-origin attacks on an existing https connection.]

This will allow the security discussion to be more relevant to the existing
security conditions, and make it harder to persistently attack a service that
is already protected via https.

Yeah, I know… my comments are probably too big and too late.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 27 Feb 2016 08:11:52 +1100

> On 27 Feb 2016, at 7:59 AM, Roy T. Fielding <[email-masked]> wrote:
> 
> to specific types of implementations (like we did for RFC7230).

Can you give a little more detail here?

> Furthermore,

I like the "secured to a specific authority" language, but...

>      as within-origin attacks on an existing https connection.]

That goes against pretty broad security practice; people don't want a server's key pair to leave a machine.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 27 Feb 2016 08:13:52 +1100

> On 27 Feb 2016, at 1:37 AM, Barry Leiba <[email-masked]> wrote:
> 

We wanted to assure that any other way to establish reasonable assurances had sufficient vetting, and that someone reading this spec could find all the different ways to establish reasonable assurances.

Any additional insights (hopefully in non-question form)?

Cheers (and thanks),

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 26 Feb 2016 14:25:25 -0800

> On Feb 26, 2016, at 1:11 PM, Mark Nottingham <[email-masked]> wrote:

Kind of too lazy at the moment to do a complete rewrite, but here is one example:

  This means that clients using an alternative service can change the host, port
  and protocol that they are using to fetch resources, but these changes MUST NOT
  be propagated to the application that is using HTTP; from that standpoint, the
  URI being accessed and all information derived from it (scheme, host, port) are
  the same as before.

would be IMO better written as

  The alternative service does not change an application's understanding of the
  origin of a given resource. A client using an alternative service MUST retain
  the original scheme, host, and port when referring to that resource even when
  it communicates with that resource via the alternative's protocol, host, and port.

and further on

  An ALTSVC frame from a server to a client on stream 0 indicates that the conveyed alternative
  service is associated with the origin contained in the Origin field of the frame. An association
  with an origin that the client does not consider authoritative for the current connection &MUST;
  be ignored.

would be better phrased as

  An ALTSVC frame from a server to a client on stream 0 indicates that the conveyed alternative
  service is associated with the origin contained in the Origin field of the frame.
  A client MUST ignore received ALTSVC frames that contain an Origin field value that
  is not authoritative for the current connection.

There are many, many more cases where MUST/SHOULD are used as statements of fact rather
than as a requirement on sender or recipient (or both).

> That goes against pretty broad security practice; people don't want a server's key pair to leave a machine.

I don't follow.  Sure, the private key shouldn't be replicated across the network,
but certainly each TLS-terminating endpoint needs to be configured with a copy of
the same website certificate, somehow.  We don't have a separate certificate
for every server in a farm.

I think proof of such shared knowledge (or something equivalent) is the minimum
necessary to allow some other server to answer authoritatively to an https request.
I don't think matching on the strings within the certificate fields is sufficient.

OTOH, my suggestion won't help with MiTM TLS, anyhow, since the client being
redirected only sees the bad M's certificate.  Bah, humbug.

Okay, maybe just require the alternative service to be secured with the original
authority and just punt on the remaining security issues as non-solved.

....Roy

---

From: Barry Leiba <[email-masked]>
Date: Sat, 27 Feb 2016 11:43:01 -0500

> We wanted to assure that any other way to establish reasonable assurances
> had sufficient vetting, and that someone reading this spec could find all the
> different ways to establish reasonable assurances.
>

Hm, I'm assume that wasn't meant to be snarky, though it sounds it.  I
needed to ask the question in order to answer the original question.

The way to assure the vetting is to say that they must be Standards
Track.  Experimental documents might or might not get sufficient
vetting.

The way to ensure that people who read this spec can find all the
extensions is to make a registry.  Extensions shouldn't generally be
"updating" the original spec.

So...
You can decide how you think the vetting will be accomplished, but if
you want it to be easy to find the new mechanisms, have this document
set up a registry and say that new mechanisms MUST be registered
there.  Then there's no concern about any "updates" rules with respect
to documents from other than Standards Track sources.

b

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 28 Feb 2016 09:10:46 +1100

> On 28 Feb 2016, at 3:43 AM, Barry Leiba <[email-masked]> wrote:
> 

No, it was not; apologies for giving the impression.

> to documents from other than Standards Track sources.

A registry doesn't feel right because this isn't a protocol element. This isn't an extension in the usual sense; it's a controlled loosening of the spec's (security-sensitive) requirements.

However, it doesn't seem like 'updates' is the right way to do this either. Upon reflection, I wonder if we really need either property (at least in such a rigorous form); people will find the mechanisms if they get implemented, and we've been happy to have OppSec as Experimental.

Anyone have a problem with dropping this?

"""
Other means of establishing them MUST be documented in an RFC that updates this specification.
"""

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Feb 2016 16:41:20 +0100

> Other means of establishing them MUST be documented in an RFC that updates this specification.

Sounds right to me.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Feb 2016 12:00:01 +1100

On 29 February 2016 at 03:53, Kari Hurtta <[email-masked]> wrote:
>
> Well, "reasonable assurances" can be protocol
> element.

They are not currently, though if we wanted them to be, then we could
write a document that updates this one to do that.  That document
might then define a registry.  No point in overengineering here.