Alt-Svc and HTTP/2 with Prior Knowledge | Re: draft-ietf-httpbis-alt-svc-12.txt

[Kari Hurtta <[e-mail]>]

Kari Hurtta <[e-mail]>: (Fri Feb 26 09:18:15 2016)
> Julian Reschke <[e-mail]>: (Thu Feb 25 15:18:55 2016)
>> On 2016-02-10 22:31, 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.
>> 
>> "new token" in what sense?
>> 
>> Best regards, Julian
> 
> 
> 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