Re: Alt-Svc and SNI

> I'd appreciate it if everyone who's interested would take a look at the
> Alt-Svc drafts that Mike Bishop presented at IETF 101:
>
> https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-01
> https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02
>
> (The latter includes a minor syntax change requested at IETF 101.)
>
> The decision at IETF 101 was that these need more attention before they can
> be considered for adoption, so please take a look.

I spotted a minor error in draft-bishop-httpbis-sni-altsvc-02: Section 1
refers to "Section 3, HTTP Co-Tenancy Fronting" of
draft-ietf-tls-sni-encryption-03, but it should be Section 4.

Section 2 is strict about requiring secondary certificate authentication
when the server's primary certificate (the one corresponding to the
Alt-Svc "sni") is not valid for the origin. "If the certificate is not
valid for the origin's hostname, the client MUST NOT make requests to
any origin corresponding to this certificate." What if the client has
some other way of authenticating the server, not using secondary
certificate authentication? I'm picturing a use case where the server
serves, say, PGP-signed documents and the necessary key has already been
shared out of band. If authentication were all that mattered, the client
would be perfectly happy to interact with such a server over plaintext
HTTP, but maybe they want to use TLS with a certain SNI for privacy
and/or to avoid blocking. Another case could be when the fronting server
is only being used as a proxy for some other, already end-to-end secure
protocol.


I'll summarize my understanding of these and related drafts from the
point of view of my interest, which is anti-blocking; i.e., preventing
an intermediary from blocking a connection based on easily observable
external characteristics like DNS query or SNI.

https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-02
is a way for an HTTP/2 server to provide additional certificates, even
after a session is underway and data has been exchanged. It assumes that
the client somehow knows which alternate origins the server supports.

https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02
provides a way, using the HTTP Alt-Svc header, for a server to inform a
client about an alternative fronting server *and* an SNI value by which
it may be addressed. (Ordinary use of Alt-Svc would have the alternative
server use the same SNI as the origin.) The fronting server replies with
a certificate valid for the given SNI value; but not necessarily once
valid for the origin the client first asked for. So the client uses
secondary certificate authentication to make sure that the fronting
server is also under control of the origin. This accomplishes two
things: 1) it's one way for clients to build a database of servers that
support multiple origins with secondary certificate authentication, and
2) it establishes end-to-end security with the origin via the fronting
server, which HTTP co-tentancy fronting (domain fronting) doesn't do. A
client still has to connect to the origin server once, in order to
receive the Alt-Svc header and learn about a fronting server.

https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02
removes the need for a client make a first bootstrapping connection to
the origin, by publishing the same information that an Alt-Svc header
contains in the DNS. By using DNS over TLS or DNS over HTTPS, the client
doesn't have to reveal to the network what its intended origin is. This
plugs the last leak where the origin might have appeared.

Start to finish, a client sends a DNS query (encrypted), receives an
ALTSVC record, connects to the given fronting server using the given
SNI, and finally secondarily authenticates with the origin inside the
TLS session.

Received on Thursday, 26 July 2018 08:44:19 UTC