Subject: SNI Extension for Alt-Svc

From: Mike Bishop <[email-masked]>
Date: Thu, 30 Nov 2017 17:56:58 +0000

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]>; [email-masked]
Cc: Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>; Patrick McManus <[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]]

Sent: 28 November 2017 18:32

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

Cc: Mark Nottingham; HTTP Working Group; Patrick McManus

Subject: RE: DRAFT: more details for HTTPtre

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

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: Ilari Liusvaara <[email-masked]>
Date: Thu, 30 Nov 2017 20:19:17 +0200

On Thu, Nov 30, 2017 at 05:56:58PM +0000, Mike Bishop wrote:
> 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.

There's also the case where the primary connection certificate is also
valid for the authority (and the primary certificate was validated).

Should the secondary certificate request be suppressed in that case?

E.g. the alt-svc has wilcard certificate and it wants to hide the
subdomain from snoopers.

-Ilari

---

From: Mike Bishop <[email-masked]>
Date: Thu, 30 Nov 2017 18:52:21 +0000

Good scenario -- I hadn't thought about that one.  I've updated the copy on GitHub to say that the client should use Secondary Certs if the certificate in the TLS handshake is not also authoritative for the origin that published the alternative.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 30, 2017 10:19 AM
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

On Thu, Nov 30, 2017 at 05:56:58PM +0000, Mike Bishop wrote:
> thanks for deciding what I'm doing next today!  😉  Forking a separate 
> thread.
> 
> 

There's also the case where the primary connection certificate is also valid for the authority (and the primary certificate was validated).

E.g. the alt-svc has wilcard certificate and it wants to hide the subdomain from snoopers.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Dec 2017 11:26:53 +1100

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]> wrote:

> 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.
>
>
>
> 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.
>
>
>
> Cc: Mark Nottingham <[email-masked]>; HTTP Working Group <
> [email-masked]>; Patrick McManus <[email-masked]>
> 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.)
>
>
>
> 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
>
> To: Lucas Pardue; [email-masked]
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Dec 2017 15:22:42 +1100

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]>
wrote:

>> 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
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>>