On Tue, 2020-06-09 at 16:33 -0400, Paul Wouters wrote: > On Tue, 9 Jun 2020, Robin Geuze wrote: > > > So lets start at the beginning, why do we want to encrypt the communication > > between then resolvers and the authoritatives in the first place. There are > > two main reasons for encrypting things. One is authentication. > > I disagree.
You could have saved yourself a lot of words by not cutting out the very next sentence of Robin's email, that said "DNSSEC already covers this aspect". > > So the second reason to encrypt things is confidentiality. > That is the only reason. The document Introduction Section also really > only mentions "no protection against snooping". There are two main reasons for encrypting things in general. There is one reason for encrypting things in DPRIVE context. Robin was just providing some context for his explanation. > > To ensure confidentiality we need to > > ensure that the nameserver we are talking to is the actual nameserver we > > want > > to talk to. Like I said before DNSSEC does not offer that guarantee, > > primarily due to the fact that while DS records are signed in the parent > > zone, NS records are not, and thus can easily be spoofed by an attacker. > > The draft does not actually do this, because it does not verify at the > child that the parent didn't make up the special DS record (See my MAY > vs MUST disussion) I'm still chewing on https://mailarchive.ietf.org/arch/msg/dns-privacy/v8qUTMNVW_9W25GUXVStr2_Jk-A If we believe there is a real danger, that verifying with the child that the DS is correct, fixes, then we should do that. But I have trouble seeing that that danger is real. > > So we need some way to identify the nameservers we should talk to. > > If you trust the parent TLSA connection and the parent to produce the right > content, then you do identify the nameservers already despite its lack > of RRSIGs, if you connected to that parent securely (and privately). I think we can currently assume that data from a parent is authenticated (by DNSSEC) but not private (because there is no DoT to the TLDs today). Any proposal that wants to support incremental deployment will have to assume traffic to parents is not private. > > Luckily we > > already have a mechanism for this, TLSA! So the simplest way to implement > > this would be to just put a TLSA record at _853._tcp.<nameserver>. There > > are > > a few problems with this approach though. Like I said before NS records are > > not to be trusted coming from the parent, this means that the TLSA record > > you > > get is initially not trustworthy either. > > This is incorrect. The TLSA lookup of the _nameserver_ name is > independent of the lookup of the _domain_ you are doing, for which > you get the (unsigned) NS records. So the TLSA record is trusted. What > you meant to say is the NS glue records are untrusted, and I agree. > But they are just as untrusted as the DS record, because it is the > same entity publishing them - the parent. They are not just as untrusted, and the distinction between them is core to any discussion about privacy or authenticity. The DS records, as published by the parent, can be verified against the parent's DNSKEY; if they verify, we know that we are seeing the DS that the parent intended to publish. Thus, the DS records are as trusted as the parent is. The NS records, as published by the parent, cannot be verified against anything. They are as trusted as the insecure path between the resolver and the parent, i.e. not trusted at all. > And we assume we have a secure > and authenticated and private connection to that parent. But we don't have that. All we have today is DNSSEC, which authenticates the DS but not the delegation NS. > Sure, you can (MAY or MUST) confirm the DS record with a child's CDS > record, but unfortunately doing that query is where you would leak > the domain name you are trying to hide when talking to this target > nameserver over DoT via the special DS record. So that does not help > you against a malicious parent. The malicious parent saw your query for yourweirdfetish.tld milliseconds before that anyway. The client-side confirmation DS query does not leak more than that. > > This approach could work. But depending on > > the data you are trying to request it could lead to a 2 times increase in > > queries at the very least, if you chain a bunch of nameservers that have > > yet > > more nameservers it at some point becomes problematic, because you need to > > request the TLSA record for each of them. And mind you, this slow down > > would > > be for all domains, not only those supporting DoT. > > My argument against the drafts focus on reducing RTTs The draft does not have a focus on reducing RTTs at all! It just so happens that, in its current form, it does not add roundtrips, which is a nice feature. It is not in any way a strict requirement. If currently unmet requirements need to be met with extra roundtrips, so be it. > > However, the downside is that your initial communication with the > > authoritative will still be plain text. You could solve this by putting a > > chain in the TLS handshake, however you would still need some way to signal > > that DoT should be attempted in the first place, otherwise resolvers would > > be > > wasting a lot of time probing which authoritatives support DoT. > > It is not a "lot of time" for the larger domain hosters which are the > only places where you could hide within the large domain crowds for > anonymity. See above. Are you suggesting to have -no parent side signal at all-? Because that won't fly. Resolvers don't have time to go around knocking at DoT ports to see what happens. > > Other solutions are definitely possible, however this is as far as > > I call tell the only one, outside TLSA records in the parent, that allows > > full start to finish encryption. > > Again, you are not making explicit that it is possible using TLSA > records at the nameserver locations as well, except that you don't > like the additional RTTs. > > On top of that, you need special support at Registry and Registrar > level for getting "bogus" DS records accepted (via EPP, CDS/CDNSKEY or > registrar/registry webgui. This on its own will prevent wide spread > adoption of this document. The document explicitly uses the 'pseudo-DNSKEY'-indirection to make it very easy for registrars to accept this - no harder than a new actual DNSSEC signing algorithm. 13/14 have made it in; 15/16 are getting there; I am sure TBD can get in there too. > Then you have the cases where people spread > their nameserves over different providers, and they will use different > DoT public keys. Imagine being cloudflare and 50 million domains have > DoT public keys in DS records at their parents. As long as one domain > did not update, they cannot update their TLS key on the DoT server. That's a choice - if a domain operator does not read their email, there can be consequences. The same applies for DNSKEY changes, just at, granted, a wildly different scale. I'm still hoping that the operator/registry problem will get fixed in some useful way, like CDS/CDNSKEY becoming supported in more than two-three TLDs. > In reality, they will never be able to change the private key of their > DoT servers. They can if they combine it with an NS rename, but it's not super pretty. > If the public key lives on ns0.cloudflare.com, they can > go ahead and update this whenever it is needed. They just need to update > their own TLSA record. > > The TLSA at nameserver solution requires no EPP, no RFC, no synchronization > between nameserver operators or between registries and nameserver > operators and can be implemented right now. I'm looking forward to reading a single, complete, coherent description of that protocol, because I've been unable to piece it together completely from your various emails - which tells me it does need an RFC. If there are no roadblocks, and it can be implemented right now, why isn't it implemented right now? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
