Re: [DNSOP] Proposal for a new record type: SNI

[Ben Schwartz <[e-mail]>]

On Fri, Feb 17, 2017 at 9:02 PM, Erik Nygren <[e-mail]> wrote:

> I wrote a similar draft a few years ago which I've been considering
> resurrecting if there is interest:
>
>     https://tools.ietf.org/html/draft-nygren-service-bindings-00
>

Thanks for pointing this out, Erik!  I think a flexible binding record like
B could be a great way to solve this problem and also enable clean future
extensibility.

With the standardization of DNS over TLS, I think your binding draft might
make more sense.  Maybe it's time to revisit.

The major concerns I have about B as described there are latency and
graceful degradation.  Does this add delay to new connections?  Does it
break connections if the client is behind a resolver that silently drops
all queries other than "A"?  My impression is that, for a new record to be
widely usable, both answers must be "no".

My draft attempts to resolve both dilemmas by (1) getting a head start on
the SYNACK and (2) specifying fallback behavior if the SNI response doesn't
arrive in time, along with a strategy to minimize the impact of fallback.
Maybe those ideas could be applied to some version of B.


>
>
> One of the big challenges that at least in the web context, browsers want
> to make as few DNS lookups as possible prior to making HTTP requests.
> (For example, some home gateways choke if too many requests are
> outstanding.)
> Having to lookup both A and AAAA is already a problem.  So if we're going
> to add
> something, ideally we'd add something that was extensible that could be
> used
> for multiple purposes.
>
> For this case, the result could be something like:
>
> _https._b.www.example.com IN B 2 0 www.example.com. { "alpn": "h2", "tls-sni": "SOME_TOKEN", "hsts": true }
> _https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn": "quic352", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN", "hsts": true }
>
> By adding this one single lookup, you both get to specify an alternate SNI,
> be able to force HTTPS-only, and specify Alternative Services (ala rfc7838
> but allowing it to be done in DNS).  Having an extensible model here also
> increases
> the value of a client doing the lookup as once the records exist other
> optional
> attributes can be added in.
>
> (Ignore the specific key/value pair examples in that expired I-D.  They
> made more
> sense when some other things were being considered.)
>
> Based on our extensive discussions in the TLS WG over the past few years,
> introducing something like this into the DNS to indicate an alternate SNI
> value
> (which might be one shared with many other hostnames) or telling the
> client
> not to send an SNI value seemed to be one of the best ways to help with
> the SNI privacy problems, at least once there is a DNS privacy path.
>
> For example, for a cert like *.example.com (perhaps with lots of other
> SANs as well)
> there is no reason the client needs to send "something-potentially-
> private.example.com" when sending
> an SNI value of "wildcard.example.com" would do just fine.  The TLS
> handshake
> is too late to learn this, but if we could move it into the DNS then
> clients
> could learn it (and potentially other useful info) before connecting.
>
> [I added DKG as he was a strong advocate of doing something in this space
> for signalling TLS SNI omission, alteration, or aliasing in DNS records.]
>
>              Erik
>
>
>
>
> On Fri, Feb 17, 2017 at 3:49 PM, Ben Schwartz <[e-mail]> wrote:
>
>> Thanks for the input everyone!  Here's an updated version with some
>> clarifications based on your feedback:
>> https://tools.ietf.org/html/draft-schwartz-dns-sni-02
>>
>> Diff:
>> https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-01&
>> url2=draft-schwartz-dns-sni-02
>>
>> I know this approach is controversial, so I'm also very curious to hear
>> any suggestions of other ways that we could fix this privacy leak without
>> slowing down everyone's connections.  As a friend put it: if everyone can
>> see you're reading justinbieber.tumblr.com, "that defeats the whole
>> point of HTTPS".
>>
>> On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz <[e-mail]> wrote:
>>
>>> Hi dnsop,
>>>
>>> I've written a draft proposal to improve the privacy of TLS connections,
>>> by letting servers use the DNS to tell clients what SNI to send.
>>>
>>> https://tools.ietf.org/html/draft-schwartz-dns-sni-01
>>>
>>> I've incorporated some helpful feedback [1] from the TLS WG, but now I
>>> could use your help analyzing the DNS side. All comments welcome; this
>>> draft will change based on your feedback.
>>>
>>> One particular issue that I could use advice on: should this be a new
>>> record type, or should it reuse/repurpose an existing type like SRV or PTR?
>>>
>>> Thanks,
>>> Ben
>>>
>>> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html
>>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>