Hello Paul, On Thu, 2020-07-16 at 15:29 -0400, Paul Wouters wrote: > On Mon, 13 Jul 2020, Peter van Dijk wrote: > > > please find below revision -01 of our proposal for enabling DoT from > > resolver to authoritative. > > DoT can be enabled regardless. This draft is not about enabling DoT.
I see my wording was inaccurate. Our proposal is an enabler technology for DoT, but it is of course entirely possible to do DoT without this document, or another document with a TLSA focus. Resolvers could even probe (although, as I said before, as a resolver developer, and on behalf of the operators running our software, I don't like that). > It is about saving a few roundtrips getting the right keys in a trusted > method. This is a misrepresentation that somehow won't go away. 'No additional roundtrips' is a benefit that fell out of the protocol tree by accident. Of course we like it, but it was never, and still is not, a requirement. > With some caveats that go along with it. > > > > The value 257, meanwhile, is believed to go down with registries much > > easier. > > What is that believe based on? Very little data, see my reply to Duane a few minutes ago for more words. > * we added a 'Design considerations' section that explains how this > > protocol came to be, and why we did not go the TLSA route. You can > > click through to it directly via > > https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01#section-9 > > It's not a good summary of the list discussion. It was not intended to be :) > I guess a draft isn't a good place for that, but I don't see the concerns of > me and Viktor > listed here at all. (context: https://mailarchive.ietf.org/arch/msg/dns-privacy/ynMI5b-UOj-jE36drrmUQGFKZxg/ ) Isn't the first sentence of this paragraph you quoted a decent summary of your concerns? : > The biggest downside to this DS-based protocol is that a change in > TLS keys on an auth may require DS updates for thousands or even > hundreds of thousands of domains. This issue is partially mitigated > by allowing backup keys to be part of those DS sets. > > I don't see how backup keys help here? If you have thousands of domains, > and one of them is unresponsble to DS updates, the auth server cannot > retire its key. , without impacting that zone. That's a choice an operator can make. > With thousands of domains the change of that happening > very quickly goes to 100%. If you tell all of them to pre-publish a > backup (or really, new) key, then you are just postponing the problem > by one interation. Correct. That's why we clearly point out this problem, and say that backup keys only 'partially mitigate' it. I do not consider this problem solved and I don't think it can be solved in scope of -this- draft. It can be solved by doing something entirely different instead (as you have been proposing in broad strokes), or it can be solved by closer operator/registry relations (as noted in that section of -01). I consider both of those options out of scope for our document. > This solution simply cannot work at scale. At operating without scale > defeats the whole purpose of anonimity. I agree that operating at scale is important for privacy purposes. But I am more optimistic than you about this solution working at scale. > A much better solution is simply to use TLSA records at the nameservers. As I've said a few times before, I look forward to reading a draft that specifies this clearly. If it was 'simple', I figure we'd be doing it already! > Sure, your first domain incurs an extra RTT but that one RTT is made > back over all the domains hosted by that auth server. Definitely! > It leaves control of the TLSA record where it belongs - at the owner of the > Dot keypair. Assuming that whoever signs the zone also operates the authoritatives, but that's no worse (just different) than the assumptions our document is making about the various parties involved with a zone. > A DS record can still be used to allow the child zone to make it > mandatory to use DoT or hardfail. I just want to say that if our draft ends up being nothing more than the inspiration for this aspect of a document that makes it to deployment, I will still be very happy with how things turned out :-) > But it does not (and should not) have a public key embedded in it to do this. Depending on how you structure the TLSA proposal, you may need the DS records to signal the names of the name servers that have TLSA, as has come up in the -00 thread a few times. > A number of other items from our previous discussion I don't see back > here either, such as the discussion around CDS so that the client can > prevent a TLD scale size MITM DoT redirect from overruling its own > policy by the abusive parent playing its own DS DoT records against > the child's wishes. (context: https://mailarchive.ietf.org/arch/msg/dns-privacy/v8qUTMNVW_9W25GUXVStr2_Jk-A/ ) Either I don't understand the subtleties, or I'm not seeing the threat model you are seeing. I've said before that I'm open to this if it prevents a threat that is realistic. (There is also, I feel, room for a variant where presence of the CDS is mandatory but checking the CDS is up to the resolver operator, perhaps?) > (And if I recall, you don't want to do this because > you are concerned about RTTs) I do care about RTTs, but I'll never say that we should strictly optimise for RTTs at the cost of security - but that does not mean that any security risk that can be imagined is serious enough to add roundtrips to a protocol. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
