RE: SNI Extension for Alt-Svc

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: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] 
Sent: Thursday, November 30, 2017 10:19 AM
To: Mike Bishop <mbishop@evequefou.be>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Mark Nottingham <mnot@mnot.net>; HTTP Working Group <ietf-http-wg@w3.org>; Patrick McManus <mcmanus@ducksong.com>
Subject: Re: SNI Extension for Alt-Svc

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

Received on Thursday, 30 November 2017 18:52:55 UTC