Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Paul Wouters <[e-mail]>]

On Fri, 29 May 2020, Peter van Dijk wrote:

> On Wed, 2020-05-27 at 21:47 -0400, Ben Schwartz wrote:
>       On Wed, May 27, 2020 at 9:27 PM Paul Wouters <[e-mail]> wrote:
>       Personally, I think it would be cleanest if we use the DS to signal
>       the DoT nameserver only by FQDN.
> 
> 
> I agree.  This is the design that I was attempting to describe.
> 
> I see now that the chain extension doesn't have to be mandatory.  A recursive that wants to use the extension can offer
> it.  If it doesn't get a chain extension in the reply, it sends a TLSA query over the
> 
> 
> emphasis on:
>
>       (as-yet-unauthenticated) TLS connection
> 
> 
> This means the TLSA query is subject to leakage by MITM. How bad that is depends on a bunch of things, but it is a wart.

The TLSA query is for the nameserver name, not the target domain name.

Presumbly, by connecting to the IP of that nameserver, you have
already revealed the information you are connecting to that nameserver,
even if none of the traffic to that IP would provide any clue about
the content. The privacy comes from many domain names being hosted by
that nameserver, and not knowing which target domain you are going to
query about.

And ofcourse, thay only works if the A/AAAA records you get back go
to another IP address used by many other domain names (and no SNI
leakage). In the end, the protection from recursive to auth is not
gaining us that much privacy, especially compared to stub to recursive.

I think what does help us is if we break the one to one relationship
between packets from stub to resolvers and from resolvers to auth
servers. But that should probably be written up in another draft document,
by someone with a PhD in statistics :)

Paul