RE: SNI Extension for Alt-Svc

Apologies for dropping you in it ;)

I do see where you’re coming from about frames. I’m not sure I 100% agree for the reasons outlined below. Perhaps a notational convention qualifying what Frame means would be enough (the one in RFC7540 is almost generic). I think there is some subtlety with frames that operate in a context of request/response, and those that operate in the context of connection.  The latter were defined in HTTP/2 as a replacement for Connection-specific header fields.

The way I read SNI Alt-Svc handling is two parts. Part 1 says a client should include SNI in the TLS handshake, part 2 seems to rely the Secondary Certificate Authentication in HTTP/2 I-D;  a Client SHOULD send a CERTIFICATE_REQUEST, and settings should be valid. Should a client that processes the sni parameter support both parts, or may it do either individually?

I’d argue that part 2 is currently restricted to a HTTP mapping that is capable of carrying Connection-level frames and settings. Alt-Svc adverts for “http/1.1” probably couldn’t do part 2. “quic” and “hq” could not support part 2 until someone defines an equivalent frame and setting in that mapping.

Lucas

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: 30 November 2017 17:57
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: Mark Nottingham <mnot@mnot.net>; HTTP Working Group <ietf-http-wg@w3.org>; Patrick McManus <mcmanus@ducksong.com>
Subject: SNI Extension for Alt-Svc


I was already planning to spin up a thread on that draft today, so thanks for deciding what I'm doing next today!  😉  Forking a separate thread.



WG, https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-00 proposes a new parameter for Alt-Svc suggesting that a client use a different (presumably generic) hostname in the TLS SNI extension, and instead gain Alt-Svc "reasonable assurances" by requesting the origin's certificate via Secondary Certificates (which is currently under Call for Adoption).  It gives a solution, albeit HTTP-specific, to SNI privacy by providing a discoverability path for which generic hostname can be used to reach a more sensitive origin under encryption.



As to the frame reference, I intentionally didn't reference which protocol, in part because Alt-Svc itself says it can be carried by various mechanisms and the definition of an Alt-Svc extension doesn't need to get into that layer.  The Alt-Svc frame for HTTP/QUIC is specified by https://tools.ietf.org/html/draft-bishop-httpbis-altsvc-quic-00.  While frames are present in both HTTP/2 and HTTP/QUIC, I don't think that makes frames a generic HTTP concept -- it's a property of certain mappings, and specified individually in each of them.



-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Thursday, November 30, 2017 2:13 AM
To: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; ilariliusvaara@welho.com<mailto:ilariliusvaara@welho.com>
Cc: Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>; HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>; Patrick McManus <mcmanus@ducksong.com<mailto:mcmanus@ducksong.com>>
Subject: RE: DRAFT: more details for HTTPtre



Hi Mike,



The connection coalescing case is interesting as it's not currently described in HTTP/QUIC. Presumably by oversight or time constraint rather than intent. (We've got a ticket open tracking that one.)



Changing track, I've just seen your SNI I-D

https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-00




References to Frames don't state a specific mapping (HTTP/2 or HTTP/QUIC). Reading between the lines this seems intentional, which got me thinking that also Frames could be described as a new HTTP semantic for binary-capable wire formats.



Lucas