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

[hardie <[e-mail]>]

On Mon, Sep 25, 2017 at 3:25 PM, Igor Lubashev <[e-mail]>
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.
>
> 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.
>
> 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.






> —
> You are receiving this because you are subscribed to this thread.
> 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