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

[Tommy Jensen <[e-mail]>]

Hey Christian,

I think scoping the problem to "well identified network" seems reasonable.

Do we need a protocol for this case? If I can get the network's DoH template from the same source I got the SSID from, then they're equivalently trusted. For enterprises, that can reuse existing network profile configuration mechanisms. For coffee shop / airport / hotel style networks, that can be printed on the same sign/card as the SSID/password (or the captive portal page as part of use terms?).

Perhaps this is exactly what you meant and I'm just being dense.

Thanks,
Tommy

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

The latest in Windows Internet Protocols:

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

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

________________________________
From: Christian Huitema <[e-mail]>
Sent: Tuesday, September 15, 2020 11:40 AM
To: Tommy Jensen <[e-mail]>; Vittorio Bertola <[e-mail]>; Tommy Pauly <[e-mail]>; Eric Rescorla <[e-mail]>
Cc: ADD Mailing list <[e-mail]>; Deen, Glenn <[e-mail]>
Subject: Re: [Add] [EXTERNAL] Re: Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)



On 9/15/2020 11:03 AM, Tommy Jensen wrote:
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.


But is that problem even solvable? The chain of event seems to be:


1) Connect to some random network

2) Get the IP address of the local Do53 resolver using DHCP

3) Infer the identity of the equivalent DoH resolver

4) Connect to said resolver

5) Verify that it is equivalent to the Do53 resolver


Step 5 checks that the identity verified by TLS identity matches the DoH identity discovered in step 3. Thus, it cannot be more secure that the process used to infer that identity. In the case of "random networks", I don't see how that can be secured. You might push it one layer down if the L2 network is somehow configured, and for example associate a DoH identity with a Wi-Fi network ID, but then we are not considering random networks anymore. Do we want to replace "random network" with "well identified network"?


-- Christian Huitema