Re: [Add] Mozilla's DoH resolver policy

[Christian Huitema <[e-mail]>]

 

> On Apr 12, 2019, at 2:48 PM, Wes Hardaker <[e-mail]> wrote:
> 
> But then you bring in the discussion of DNSSEC and authenticity, which
> is the only current way to ensure end-to-end data integrity and combine
> this with Martin's statement of
> 
>> We don't believe that DNSSEC is essential to our primary goals, which
>> are improving privacy of browsing activity.
> 
> Which clearly shows that between the above three, they're willing to
> sacrifice some level of authenticity to achieve better latency and
> privacy.  Note, though, that this choice isn't wrong.  It's a choice.  I
> may choose a different one, as may others.  And I'm more than sure my
> list above is incomplete from an ideological stand point; it just
> happens to be the three biggest I could think of.

On the other hand, DNSSEC does not guarantee authenticity either. It guarantees that the mappings of name to IP address is authentic, but that's not the same thing as guaranteeing that the connection actually terminates at the authentic end point. There could well be a NAT somewhere that translates the IP address and delivers the packets to a different server. See for example the many cases of rerouting 8.8.8.8 traffic to a different server.

On the web, authenticity is provided by the server identity verification built in TLS and used by HTTPS. Arguably, once you have HTTPS and authenticate the server, then DNSSEC does not provide any additional guarantee.

What DNSSEC provides is something else. If the name resolution points to the IP address of the wrong server, the TLS authentication will fail, and so will the connection. Falsified name resolution is thus a form of DOS attack, and DNSSEC protects against that. That's nice, but not essential.

Of course, DNSSEC is useful for other scenarios, such as retrieving keys. But these are not quite the main web scenarios.

-- Christian Huitema