Subject: RE: SNI Extension for Alt-Svc

From: Lucas Pardue <[email-masked]>
Date: Fri, 1 Dec 2017 14:27:58 +0000

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 1 Dec 2017 18:04:36 +0000

The two pieces are inter-related.  The parameter recommends using a different SNI, which therefore isn’t guaranteed to get you the certificate you actually need to verify.  As Ilari pointed out, it might still be the right certificate – but if it’s not, you need a channel to retrieve the correct one post-handshake.  You’re correct that we’d need to define Secondary Certs for HTTP/QUIC before an “hq” alternative would be able to do the second part.

From: Lucas Pardue [mailto:[email-masked]]
Sent: Friday, December 1, 2017 6:28 AM
To: Mike Bishop <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>; Patrick McManus <[email-masked]>
Subject: RE: SNI Extension for Alt-Svc

Lucas

To: Lucas Pardue <[email-masked]<mailto:[email-masked]>>

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 2:13 AM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Mark Nottingham <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>
Subject: RE: DRAFT: more details for HTTPtre

Hi Mike,

Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 1 Dec 2017 18:19:14 +0000

The two pieces are inter-related.  The parameter recommends using a different SNI, which therefore isn’t guaranteed to get you the certificate you actually need to verify.  As Ilari pointed out, it might still be the right certificate – but if it’s not, you need a channel to retrieve the correct one post-handshake.

Right. Is that possible with HTTP/1.1? I.e. through renegotiation or something?

Lucas

To: Mike Bishop <[email-masked]<mailto:[email-masked]>>

Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 2:13 AM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Mark Nottingham <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>
Subject: RE: DRAFT: more details for HTTPtre

Hi Mike,

Lucas

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Mike Bishop <[email-masked]>
Date: Mon, 4 Dec 2017 19:28:06 +0000

*waggles hand back and forth*

Technically, you could renegotiate and request a different server identity, but something tells me that’s prohibited somewhere.  (I thought it was in RFC 6066, but I don’t see it.)  At any rate, I doubt there are any TLS implementations that support that and even fewer that test it.  I wouldn’t count on the ability to do this under HTTP/1.1.  So you’re correct that an HTTP/1.1 alternative would only be able to work with a wildcard subdomain certificate in the handshake, and HTTP/QUIC would need a Secondary Certificates port.

Sent: Friday, December 1, 2017 10:19 AM

Lucas

Lucas

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 2:13 AM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Mark Nottingham <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>
Subject: RE: DRAFT: more details for HTTPtre

Hi Mike,

Lucas

http://www.bbc.co.uk

---------------------

---

From: Mike Bishop <[email-masked]>
Date: Mon, 4 Dec 2017 19:34:54 +0000

Nope, that’s the discussion in Security Considerations, basically.

It’s the same problem that HSTS and HPKP have by themselves – you have to connect to the site at least once to learn how you should have connected to the site.  Secondary Certs means a client that knows two domains are collocated could do this already.  This allows the server to use Alt-Svc to recommend a public-facing domain for the client to use, and requires less initiative from the client.  But you need a bootstrap either way.

Alt-Svc in DNS keeps coming up and would enable the bootstrapping, if you’re willing to pay the latency cost on browsing or race the resolutions.  However (as SC notes), that would allow a crawler to build a map of “hidden” domains behind the public-facing one by making DNS queries, so pick your poison carefully.

From: Martin Thomson [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 8:23 PM
To: Mike Bishop <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>; Patrick McManus <[email-masked]>
Subject: Re: SNI Extension for Alt-Svc

One thought that has been bugging me.  This doesn't seem to do anything for the bootstrapping scenario.  At least, not any more than the secondary certs on its own does.  Was I missing something?

On Fri, Dec 1, 2017 at 11:26 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mike,

Interesting idea.

How would you imagine this interacting with a client's TLS session cache?  Specifying unique SNI values that contain encrypted information is interesting, but you want to ensure that the TLS session cache for the hostname is not used or you could get linkability based on the value of a session ID or session ticket.

Also, I think that it would be good to have some sort of commitment to TLS 1.3 support.  Then you could rely on the server certificate being protected.  I don't want to have to rely on secondary certificates and the associated delays.  This seems like it could be a reasonable alternative to the secondary certificates work.

On Fri, Dec 1, 2017 at 4:56 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 30, 2017 2:13 AM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Mark Nottingham <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>
Subject: RE: DRAFT: more details for HTTPtre

Hi Mike,

Lucas

________________________________________

From: Mike Bishop [[email-masked]<mailto:[email-masked]>]

Sent: 28 November 2017 18:32

To: Lucas Pardue; [email-masked]<mailto:[email-masked]>

Cc: Mark Nottingham; HTTP Working Group; Patrick McManus

I agree that HPACK is largely decouplable from HTTP/2, or HTTP.  The core of the protocol is a general-purpose compression algorithm for streaming key-value dictionaries, rather than straight text.  The pieces that bind it to H2 are incidental, and perhaps we could have structured it differently.

Coalescing isn't a new semantic -- each HTTP mapping defines how parallelism and connection reuse should work in that mapping.  HTTP/2 simply happens to define it more expansively than HTTP/1.1.

-----------------------------

http://www.bbc.co.uk

If you have received it in

error, please delete it from your system.

Do not use, copy or disclose the

information in any way nor act in reliance on it and notify the sender immediately.

-----------------------------