Subject: [quicwg/base-drafts] SIN requirement (#794)

From: Igor Lubashev <[email-masked]>
Date: Mon, 25 Sep 2017 22:25:23 +0000 (UTC)

Per @martinthomson in #495, SNI is currently not required to be used in QUIC, while it is required to be used in HTTP/2.  TLS 1.3 requires SNI to be implemented but apparently does not require it be to used.

This is a proposal to require SNI for QUIC.

The main reason for this is the scarcity of IPv4 addresses.  As long as something is not required, someone will not implement it.  As long as there are enough clients that do not use SNI, virtual service providers will continue to require a large number of IPv4 addresses.  Since IPv4 address conservation is currently a high priority for the Internet, QUIC should strongly encourage (or, better, require) technologies that further this conservation goal.

-- 
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/794

---

From: hardie <[email-masked]>
Date: Mon, 25 Sep 2017 22:50:39 +0000 (UTC)

On Mon, Sep 25, 2017 at 3:25 PM, Igor Lubashev <[email-masked]>
wrote:

> Per @martinthomson <https://github.com/martinthomson> in #495
> <https://github.com/quicwg/base-drafts/issues/495>, SNI is currently not
> required to be used in QUIC, while it is required to be used in HTTP/2. TLS
> 1.3 requires SNI to be implemented but apparently does not require it be to
> used.
>
> The main reason for this is the scarcity of IPv4 addresses. As long as
> something is not required, someone will not implement it. As long as there
> are enough clients that do not use SNI, virtual service providers will
> continue to require a large number of IPv4 addresses. Since IPv4 address
> conservation is currently a high priority for the Internet, QUIC should
> strongly encourage (or, better, require) technologies that further this
> conservation goal.
>
> Nit:  I believe you mean to require SNI, not SIN, though no doubt we'll
get the latter some way or another.

Substantive:  I believe that if we require SNI, we require some method of
preserving the privacy of that SNI.

I'm not sure that the TLS in TLS tunneling solution for encrypted SNI that
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 puts forward
is as neat in the QUIC case.  If the fronting server isn't a QUIC service
but is purely a TLS-in-TLS tunneling proxy, then it probably works as
described.  But if it is both a QUIC service and fronting for other
QUIC-in-TLS-in-TLS services,  then I think we need to carefully work
through how the second  aspects fits in with other QUIC assumptions about
where the transport/application boundary fits.

I think the dual service is something that we need to consider for some of
the same reasons set out in sni-encyption-00 regarding replay attacks: if
at attacker connecting to a fronting service doesn't connect to a hidden
service behind it and thus gets a "blank service", it will make the server
stand out as a fronting server.  To avoid that, I suspect folks would like
to present servers that are both fronting services and servers for an
existing application protocol.

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/794>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5MQtFXGsG_sBF9SbxmdC55nGWG2aks5smChQgaJpZM4PjbM9>
> .
>

-- 
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/794#issuecomment-332036205

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Sep 2017 23:41:45 +0000 (UTC)

@hardie is correct in that QUIC makes TLS-in-TLS more difficult.  Though that is not the only alternative available.  It is not impossible to do TLS-in-TLS, but it would require some non-trivial effort.

But I think that we should first address the meta-comment.  Do we want to change the character of QUIC such that it can/MUST support SNI encryption?  That's a different question to the one that I think @igorlord had, which is probably just "should HTTP over QUIC require SNI?"  The answer to each might be different.

-- 
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/794#issuecomment-332044373

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 26 Sep 2017 00:24:08 +0000 (UTC)

> Nit:  I believe you mean to require SNI, not SIN,

Thanks, fixed.  (There are plenty SINs already; no need for requiring a new one.)

> SNI privacy

SNI privacy looks like a TLS extension, and it could be developed separately from QUIC. @martinthomson has had enough wisdom to open #795 to make sure we at least discuss the topic.

A solution along the lines of tls-sni-encryption-00 would certainly benefit from a 1-RTT encrypted Finished (as is suggested in #785), since Finished could include bits to trigger "chained SNI" and TLS-in TLS negotiation.  It would be a nice solution, since it would allow server side of the application to be relatively oblivious to the TLS tunneling that is going on.

An application-specific implementation, where the client talks first, could provide an application-specific way to trigger SNI chaining and TLS-in-TLS negotiation.

-- 
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/794#issuecomment-332050320

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 26 Sep 2017 00:35:51 +0000 (UTC)

> "should HTTP over QUIC require SNI?"

This is a fine first question to answer, and I am happy to change this issue to address this specifically.

I think a generic question of whether a client is required to identify whose TLS certificate it is looking for, regardless of the app, is also interesting to settle.

-- 
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/794#issuecomment-332051830