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

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 23:03:15 -0700

Closed #795.

-- 
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#event-1729490798

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 23:03:15 -0700

My assessment here is that this will either happen in TLS or not and we don't need to track it specially in QUIC.  No solution that I'm aware of will require changes to QUIC to be used because it all happens entirely outside the protocol (e.g., in DNS) or entirely within TLS.

There's a small risk that the overzealous use of padding in some cases might make it hard for QUIC to benefit from this, or that the arrangement of the design is too narrow in applicability for it to apply to QUIC, but that seems unlikely given the actors.  Those involved are motivated to have it work for QUIC.

So I'm going to close this.  If we need some changes to QUIC to support a particular design, we can discuss the specific requirements as they come up.  Most likely, any such discussion would need to be left to v2.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 11 Jul 2018 23:15:33 -0700

There is one case I could see: An external DNS like solution affects the initial random ODCID so it isn't entirely random and routes to the appropriate target.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 23:43:56 -0700

The specs wouldn't necessarily change there.  It's basically a property of QUIC that the destination connection ID in a client's Initial packet is not controlled by the server, and therefore not really appropriate for use in routing packets in the same way that a connection ID that the server chooses is.

If a solution for encrypting SNI proposed new ways of selecting the destination connection ID (I haven't seen that suggested, but I'll concede that it's possible), then they would have to work within that constraint.  Either that, or request changes from QUIC.

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