On Sat, 23 May 2020, Peter van Dijk wrote:
As I remarked in my reply to Jeremy, I spent quite some time thinking about how to do the signalling&pinning with actual TLSA records, but I never ended up with a satisfactory solution.
But I don't think your current solution is satisfactory either. It is basically the same thing we told djb about dnscurve - you cannot abuse an RRtype for something else. Whether you put a pubkey in the NS record LHS, or a TLS key inside a DNSKEY - you are abusing the RRtype system. But I also don't see the gains of abusing DNSKEY, because you already need to query the DNSKEY of the domain to get the pesudeo-DNSKEY key, and then you already lost your privacy. I think it is worth it to take a step back and consider what we are trying to protect here. If we are trying to prevent someone from seeing I am going to go to nohats.ca, then revealing I'm querying for the DNSKEY RRset for nohats.ca means we already failed. So I'm going to define DNS privacy as "Prevent leaking information that I am going to domain XXXX". It hardly matters what we query of domain XXXX. The content of the A record is not the loss of privacy. The loss of privacy is that we were trying to go to domain XXXX. Let's assume we can connect to the .ca nameservers securely and privately. We query for nohats.ca. If there is no DS, all bets are off as the child cannot signal anything to us securely. If there is a DS, we also got NS records, and possibly A/AAAA glue. In the case of getting A/AAAA glue, we can connect using DoT if we knew this was an option (eg signaled in the DS record). In the case of getting only NS records, we would have to securely and privately look up those records first. Let's say we get ns.example.com and no glue, we go through another iteration of this until we get A/AAAA glue and can connect using DoT if the DS record could have signaled this. If the DS record somehow conveyed "yes you can do DoT", you can now connect to that IP on port 853 and send your query. We still need to authenticate this TLS channel. Conveying that you can do DoT using DS can only really be done by overloading the record type. I don't like it, but the other other choice we have to opportunistically just try port 853, and in 20 years perhaps we can shut down port 53 like we are now getting ready to shut down port 80. The opportunistic part is tricky, because it does allow an attacker to RST/filter your 853 connection and downgrading you to plaintext - where as if we signal this in the DS record, we could prevent downgrade and hard fail if privacy is that important to us that we prefer not to connect over leaking that we are trying to connect. If we don't want to hard fail, then I think we should just drop this draft and use opportunistic. If we want to offer hard fail, then some draft is still useful. I would use the keytag record set to 0 to mean this DS record is not a real DNSKEY but "something else". Whether you need anything else is debatable. You could use the digest field to stuff in a public key. Then you can connect to the nameserver, and presuming that it is a large DNS hoster like godaddy, you could verify the TLS connection before sending your first nohats.ca related query. You can optimize this with False Start, Session Resumption, etc. At the child, you can leave a CDS record of the identical special DS record at the parent, as cryptogrpahic proof that the special DS record for DoT at the parent was actually something the child wanted its parent to publish. Again, this would require another round trip to confirm that the parent wasn't sending you to a rogue nameserver. But at least you are ensured the parent isn't running a global TLS MITM nameserver that logs and forwards all queries. No additional pseudo-DNSKEYs are needed. In your draft, you cannot connect with privacy until you obtain the base64 encoded TLS key embedded in the DNSKEY RRset. I'm saying this is too late - you already revealed the only important bit of information, that you are trying to visit "nohats.ca". There might be exceptions, like subdomain.wordpress.com or subdomain.livejournal.com but in 99% of the cases, the domain name itself is the valuable information to keep private.
Also, as Petr pointed out, our DNSKEY/DS-based proposal does not involve additional queries and thus roundtrips; as far as I can imagine, anything using TLSA would need extra queries.
I don't believe a working solution cannot be allowed to introduce an extra roundtrip. With the amount of CNAME's splattered all over the world, I think trying to hack around avoiding a roundtrip is not worth it. Especially for DNSKEY/DS records, which should not have TTL=1 and are happilly cached for extended periods of time. As I pointed out above. If you want to protect losing privacy to a rogue parent, a number of additional roundtrips are required anyway. Saving one of them isn't worth creating pseudo-DNSKEY records for. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
