Subject: Re: Alt-Svc and SNI

From: David Fifield <[email-masked]>
Date: Thu, 26 Jul 2018 01:43:16 -0700

> 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.

---

From: Mike Bishop <[email-masked]>
Date: Sat, 28 Jul 2018 00:27:17 +0000

Thanks for catching that!  I'm assuming it was correct and then the document grew an extra section.  The toolchain can keep track of which revision of the document is current when we publish, but it can't follow when sections move around.  (Yet?)  Your summary of the documents and how they interact looks accurate, with one piece I'd add to your note on Secondary Certificates:  Other ways for a client to learn about additional origins are:
  - Server presents an additional certificate without being asked (though servers with many certificates will have to develop their own logic for when to present which certificates)
  - Client can learn about additional origins a server claims via the ORIGIN frame, RFC 8336

As to the authenticated resource payload, I'm inclined to think that scenario is out of scope for Alt-Svc.  Individual resources may well have that property.  A client might even be configured to know that all resources on a given host have that property.  However, Alt-Svc makes a claim about the HTTP origin, and that concept isn't one that HTTP origins currently have a way to describe.

-----Original Message-----
From: David Fifield <[email-masked]> 
Sent: Thursday, July 26, 2018 1:43 AM
To: [email-masked]
Subject: 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:
>
> 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.