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

[Martin Thomson <[e-mail]>]

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