RE: SNI Extension for Alt-Svc

[Lucas Pardue <[e-mail]>]

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:[e-mail]]
Sent: 30 November 2017 17:57
To: Lucas Pardue <[e-mail]>
Cc: Mark Nottingham <[e-mail]>; HTTP Working Group <[e-mail]>; Patrick McManus <[e-mail]>
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:[e-mail]]
Sent: Thursday, November 30, 2017 2:13 AM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Mark Nottingham <[e-mail]<mailto:[e-mail]>>; HTTP Working Group <[e-mail]<mailto:[e-mail]>>; Patrick McManus <[e-mail]<mailto:[e-mail]>>
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