Re: [dns-privacy] Status of draft-ietf-dprive-rfc7626-bis?
On Wed, Sep 23, 2020 at 5:20 AM Brian Haberman wrote: > > > > Other recent submissions have changed their references to RFC 7626. What > > changes in the 7626-bis document are important to you? > > > > The changes made to the BCP document were driven by feedback from IESG > members who rightly pointed out that the BCP referred to text originally > found in 7626 and that 7626-bis was in a state of churn. > That makes sense to me. I was only pointing out that the same tradeoff might apply to Paul's document. I personally don't understand what 7626-bis adds, and it doesn't seem like completing the revision has been a pressing concern. thanks, Rob ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] the rec/auth dot problem, was Re: Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin
Peter van Dijk wrote: > > (and I agree with Paul Hoffman and others that we have plenty of > proposals, fully worked out or not, but not a lot of agreement on what > the actual shape is of the problem we are solving.) At what level of detail is it not clear? The problem I see is that none of the plausible ways to a solution are particularly attractive. The overall shape of the problem has always seemed to me to be straightforward to map out. Here's a quick sketch, not going into too much detail and with plenty of gaps. Problem: given a referral, how can a resolver find out which (if any) authoritative servers support DoT (or some other private transport) without leaking any of the query (especially the qname)? Solution 1: no signalling Solution 2: signalling in the DNS message protocol Solution 3: signalling in the DNS zone data tree Solution 4: signalling outside the DNS (I'll unpack these below) Observation: if there is an authenticated signal then authenticated encryption and unauthenticated encryption are equally difficicult, so there's no benefit and significant loss of security to do DoT without authentication. Observation: a lot of these solution sketches add multiple round trips to the query time (even if you don't count TLS connection setup), so I won't mention it as a problem every time, even though latency is important for choosing between them. (this is just a sketchy map not a michelin guide) Solution 1.1: just try DoT Problem 1.1.1: Trying the connection is likely to be slow because SYN packets to unexpected ports are often silently dropped. Problem 1.1.2: There isn't a reliable way to authenticate the server: many delegations use non-canonical authoritative server names so even if the server supports DoT its certificate is likely to have the wrong name. Problem 1.1.3: TOFU authentication doesn't support rollover. Solution 1.?: any others under the "no signalling" header? Problem 2: in-protocol upgrades are subject to downgrade attacks Solution 2.1: use RFC 8490 DSO to do STARTTLS Problem 2.1.1: everyone hates STARTTLS Problems 1.1.2 and 1.1.3 apply to solution 2.1 (and also 1.1.1 unless you are very optimistic) Solution 2.2: send a preflight request to ask about DoT support Problem 2.2: if the request goes over UDP it might not always go to the same server, so this solution implicitly requires clustered servers to have very tightly matching configurations. Question 2.2: does it look like a normal query and if so what is the qname? Solution 2.2.1: qname is a special-use name something.arpa Problem 2.2.1.1: can't be authenticated so 1.1.2 and 1.1.4 apply Solution 2.2.2: qname is the server name can be authenticated Problem 2.2.2.1: requires server to be authoritative for its name Problem 2.2.2.2: leaks the zone name for in-bailiwick delegations Solution 2.2.3: qname is the zone name can be authenticated Problem 2.2.3.1: not very private, is it? Problem 2.2.3.2: awkward to put information about the server in every zone it serves - co-ordination problem between server operators and zone owners Solution 2.?: any other in-protocol upgrades? Solution 3.1: signalling in the delegation can be authenticated Problem 3.1.1: EPP Problem 3.1.2: instead of being O(servers) the provisioning problem is at least O(zones) and maybe O(zones*servers) Problem 3.1.3: operator vs registrant vs registrar communications Solution 3.2: signalling at the server name (or TLSA-style prefixed server name) can be authenticated Problem 3.2.1: leaks the zone name for in-bailiwick delegations Solution 3.3: signalling at the server IP address reverse DNS (or TLSA-style prefixed reverse DNS) can be authenticated Problem 3.3.1: might have awkward dependency loops between forward and reverse DNS Note 3.3.2: need to explain why this is OK for DoT when we thought it was not for ACME Solution 3.4: DoT lookaside zones (think DLV) Problem 3.4.1: relies on more third parties for authentication Problem 3.4.2: where does the data come from and how do we know it is correct? Solution 3.5: signalling in the parent zone separate from the delegation (like example._dot.com) Problem 3.5.*: similar to 3.1.* Solution 3.?: surely I have covered all the plausible options for putting this in normal DNS data?! Problem 4.1: difficult to do out-of-DNS signalling and avoid centralization Problem 4.2: these generally rely on a third party (outside the zone's delegation path) for authentication Problem 4.3: can these options scale big enough? Problem 4.4: where does the data come from and how do we know it is correct? Solution 4.1: distribute a big public DoT server list (think public suffix list) Solution 4.2: rather than distributing a big list, use k-anonymity like Troy Hunt's pwned passwords query API Solution 4.3: parent zone has a pointer to a non-DNS DoT server list and/or non-DNS query API server Solution 4.?: any others? Tony. -- f.anthony.n.finchhttp://dotat.at/
Re: [dns-privacy] Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin
Hi Ben, On Mon, 2020-08-10 at 10:07 -0400, Ben Schwartz wrote: > I do not support adopting this draft as-is. I think this construction is > very clever, and points us in the right direction for authentication, but > it's extremely inflexible in regard to the transport protocol and key > updates. As the draft notes, "a change in TLS keys on an auth may require DS > updates for thousands or even hundreds of thousands of domains", which may > not be under the administrative control of the authoritative server operator. > This seems likely to make key rotation effectively impossible in many > potential deployments, as rotation cannot occur until _all_ customers have > updated their zones. > > This draft could be suitable for "experimental" status, but for a "standards > track" document I think we should start with a design that addresses these > problems. Because I still believe this approach would work for many domain owners, I think experimental would make perfect sense, but at this point I'm unsure the WG even has appetite for that, and that is very understandable. (and I agree with Paul Hoffman and others that we have plenty of proposals, fully worked out or not, but not a lot of agreement on what the actual shape is of the problem we are solving.) 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
Re: [dns-privacy] Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin
Hi Paul, On Tue, 2020-08-11 at 21:43 -0400, Paul Wouters wrote: > I am against adoption for two reasons. The draft as it currently is, > requires that domain name owners and nameserver hosting administrators > synchronise their nameserver TLS keys. This is impossible to do at > scale. For various reasons, also unrelated to this draft, I hope that syncing problem gets solved some day! > Second, this method introduces a possible national MITM by the TLD being > able to put in TLD wide DS records that might be published against the > wishes of the childen within the TLD. A protection mechanism via the child > confirming the parent record with a CDS record would address this concern. I saw no appetite for that from other WG participants, which is why this has not made it to the text, but I'm still not opposed to it. > I truly wish the idea would work. And I still believe a DNSKEY bit on > the DNSKEY to signal encrypted DNS availability would be worth pursuing. As I said before, if this is the contribution that makes some other draft work, I'll also be happy :) 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
Re: [dns-privacy] Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin
Thanks Brian, that is my reading of the thread as well. I agree that the conversation that's been had provides ample input for the requirements draft. On Mon, 2020-09-21 at 14:13 -0400, Brian Haberman wrote: > Hi all, > The chairs have determined there is currently no support to adopt > this document at this time. The chairs encourage the authors and the WG > to discuss how this approach may inform the phase 2 requirements draft. > > Regards, > Brian > > On 8/10/20 7:44 AM, Brian Haberman wrote: > > Hi all, > > During the DPRIVE session at IETF108, we discussed adopting > > https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ > > and the results were inconclusive. The chairs would like to start a > > 2-week call for adoption to determine the WG's interest in this work. > > > > Please respond to the mailing list with your view (positive or > > negative) and supporting rationale on adopting the draft. This WGLC will > > end on 2020-08-24 at 23:59 UTC. > > > > Regards, > > Brian & Tim > > 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
