Subject: Re: [quicwg/base-drafts] SNI encryption (#795)

From: Mike Bishop <[email-masked]>
Date: Wed, 25 Oct 2017 14:39:25 -0700

Secondary certificates seems like a good way to achieve this for HTTP/* over TLS.  Put your CERTIFICATE_REQUEST for the real hostname in 0-RTT data.  A more general possibility would be the "tls1.3" ALPN token, where you carry a TLS 1.3 session on Stream 1, with the ClientHello (in 0-RTT data if you can) and use of other streams is discouraged or prohibited.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/795#issuecomment-339479877

---

From: hardie <[email-masked]>
Date: Wed, 25 Oct 2017 15:44:37 -0700

On Wed, Oct 25, 2017 at 2:39 PM, Mike Bishop <[email-masked]>
wrote:

> Secondary certificates seems like a good way to achieve this for HTTP/*
> over TLS. Put your CERTIFICATE_REQUEST for the real hostname in 0-RTT data.
> A more general possibility would be the "tls1.3" ALPN token, where you
> carry a TLS 1.3 session on Stream 1, with the ClientHello (in 0-RTT data if
> you can) and use of other streams is discouraged or prohibited.
>
> I think that means that the ALPN token can't be used to select the
protocol.  When we get to the point of having multiple protocols, some
subset of which might be present but served by different back end
processes, that could pose a problem.  Would you be okay with
$PROTOCOL.tls1.3 as a pattern?  That can still get you to the point where
the server name is encrypted, even if the protocol is known to anyone able
to observe the ALPN token.

Ted

> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/795#issuecomment-339479877>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5GJOEkjMNuD9_e8EVqxvrUafm5Hrks5sv6qMgaJpZM4PjfJL>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/795#issuecomment-339496867

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Oct 2017 16:22:14 -0700

The issue here is not whether we expose the use of a particular protocol.  Those tend to have small cardinality, so don't tend to compromise K-anonymity much by their exposure.  But I wouldn't shift the load to ALPN.

If any protocol can build similar capabilities to what is proposed for HTTP, then they benefit from the same advantages vis-a-vis SNI protection.  If a generic capability is what is needed, I don't think that ALPN is where I would start looking, I'd build a QUIC extension in some form.

An extension would either replicate the HTTP/2 certificates functionality, or do QUIC-in-QUIC in some way (probably by putting TLS in a stream and then exporting new keys when it is done and using a key update to manage their installation).  Christian and ekr have done some work here and have a few options in their TLS doc.  Some, if not all, of the basic designs work for QUIC.  None of them use ALPN, which would create an undesirable secondary signal.

(Also, every time someone suggests we make ALPN anything other than opaque, I cringe.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/795#issuecomment-339503516