Re: [Add] [EXTERNAL] Re: Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)

[Tommy Jensen <[e-mail]>]

Hey Vittorio,

To follow up on this and from our conversation on Jabber for the same proposal:

> What would be the security problem if 10.0.0.1 via Do53 received a "resolver discovery" query, forwarded it to the main resolver, received a DNSSEC-signed response, forwarded you the response, and the response included both a DoH URI and a TLSA record that the DoH resolver's certificate has to match?

The problem is there's no name associated with the original Do53 server. The client, in order to trust the DNSSEC claim, needs to know the name being signed in advance. Otherwise, an attacker can intercept and replace the DNSSEC-signed DoH URI and TLSA record with their own DoH server information, correctly DNSSEC signed.

A client in this scenario can't distinguish between valid signed data for "doh.exmaple-isp.com" and "doh.example-attacker.com". Realistically, this will complicate any attempt to validate ownership between a non-public Do53 IP address and a DoH server. Until the network authentication problem is more generally solved, I don't think authenticating local DNS servers is a good use of the WG's time.

Thanks,
Tommy

================================================

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Add <[e-mail]> on behalf of Vittorio Bertola <vittorio.bertola=[e-mail]>
Sent: Tuesday, September 15, 2020 5:43 AM
To: Tommy Pauly <tpauly=[e-mail]>; Eric Rescorla <[e-mail]>
Cc: ADD Mailing list <[e-mail]>; Deen, Glenn <[e-mail]>
Subject: [EXTERNAL] Re: [Add] Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)


Il 15/09/2020 04:48 Tommy Pauly <tpauly=[e-mail]> ha scritto:

What might not be possible, on the other hand, is to usefully authenticate a deployment model where the resolver or forwarder is some private/local address that’s running on a router itself–unless this is a managed network or managed device that has some out of band mechanism to trust or configure resolvers (at which point we don’t need discovery mechanisms). I think the case of trying to find an equivalent and trusted resolver to the one running on 10.0.0.1 on my router ends up being indistinguishable from an attack scenario.
What would be the security problem if 10.0.0.1 via Do53 received a "resolver discovery" query, forwarded it to the main resolver, received a DNSSEC-signed response, forwarded you the response, and the response included both a DoH URI and a TLSA record that the DoH resolver's certificate has to match?
But these scenarios likely aren’t worth solving this way anyhow—if the DoH server isn’t on my router itself, but hosted in the ISP network, the network would do better to provision the address of that ISP server instead of a local address;
It has been explained that this would as a minimum require firmware/configuration upgrades on millions of CPEs, and as a maximum be impossible because CPEs have the forwarding configuration hardwired or are out of support by the manufacturer. Perhaps in 5-10 years, not now.
and if I really have a DoH server running locally, the router would presumably be able to upgrade to be able to provision the DoH information directly in DHCP/RA/PvD.
A DHCP extension to advertise a DoH URI was proposed at an IETF meeting over a year ago. It was rejected as too insecure, but if that assessment changes, of course it could be considered.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail]<mailto:[e-mail]>
Office @ Via Treviso 12, 10144 Torino, Italy