Re: [dns-privacy] [dnsdir] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
On Mon, 2023-07-03 at 10:50 +0200, Peter van Dijk wrote: > On Fri, 2023-06-30 at 16:32 +, Paul Hoffman via dnsdir wrote: > > The current wording at the end of 4.6.9 is: > > But if `R` is unsuccessful (e.g. timeout or connection closed): > > > > I believe that changing that to the following would fix the problem you > > describe: > > But if `R` is unsuccessful (RCODE other than 0, timeout, connection > > closed): > > > > Does that fix your case and not break other cases? > > You need to allow, at a minimum, RCODE 3 (NXDomain) too. After a poke from Paul, a clearer version: both RCODE 0 and RCODE 3 can be good responses from an auth. (In hindsight, it's a terrible mistake that 1035 calls RCODE 3 "Name Error" - it's not an error.) 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] [dnsdir] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
On Fri, 2023-06-30 at 16:32 +, Paul Hoffman via dnsdir wrote: > The current wording at the end of 4.6.9 is: > But if `R` is unsuccessful (e.g. timeout or connection closed): > > I believe that changing that to the following would fix the problem you > describe: > But if `R` is unsuccessful (RCODE other than 0, timeout, connection > closed): > > Does that fix your case and not break other cases? You need to allow, at a minimum, RCODE 3 (NXDomain) too. 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
[dns-privacy] PowerDNS implementation of unilateral probing
Hello, we released PowerDNS Recursor 4.7.0 [1] with an implementation of unilateral probing for ADoT. The implementation does not follow the existing draft to the letter, but was strongly inspired by it. Otto Moerbeek wrote a nice article about the implementation [2]. We welcome any feedback on the implementation and the article, and we hope that having this implementation out there will help all of us gain the necessary operational experience to progress the working group's goals. (Jerry Lundström already found a bug, which has been addressed, and the fix will be released in version 4.7.1 [3]) [1] https://blog.powerdns.com/2022/05/30/powerdns-recursor-4-7-0-released/ [2] https://blog.powerdns.com/2022/06/13/probing-dot-support-of-authoritative-servers-just-try-it/ [3] https://github.com/PowerDNS/pdns/pull/11692 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] please adopt draft-dkgjsal-dprive-unilateral-probing as a WG work item Re: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-02.txt
On Thu, 2022-02-03 at 12:59 -0500, Daniel Kahn Gillmor wrote:
> Hi Peter, DPRIVE folks--
>
> On Thu 2022-02-03 11:03:35 +0100, Peter van Dijk wrote:
> > Speaking only for myself: some of the parts still seem too prescriptive
> > to me (but I know I haven't been clear on what parts!). Examples: 4.3.1
> > seems too focused on some specific load balancer implementations, and
> > causes a terrible combinatorial state explosion.
>
> §4.3.1 ("Separate State for Each of the Recursive Resolver's Own IP
> Addresses") was added specifically in response to concerns raised by
> load balancer operators, in coordination with §3.1 (guidance to the pool
> operators themselves), with a goal of convincing anyone interested that
> the system isn't going to be overwhelming as long as everyone involved
> sticks to a few simple and plausible guidelines.
Right, that makes sense!
> I don't think that there is a combinatorial state explosion here --
> every system that queries from a different outbound address just keeps
> its own copy of its state, no?
If they are separate systems, yes!
Some resolvers (such as Unbound) can use a whole /64 of v6 (or a /24 of
v4, if you happen to have one lying around) as extra entropy. In those
cases, it would really be a lot of extra state.
> It's possible that some other set of choices can offer equally
> unthreatening system analysis, but if we're proposing an alternative, we
> should write it down explicitly so that people can identify potential
> problems. Being able to reason about the system as a whole is an
> important part of this kind of description.
Agreed.
>
> One reason to be concerned about divergence from the described approach
> is if it interacts poorly with someone else's *different* divergence
> from approaches described in the draft, for example the guidance around
> operating and dealing with pools that we're discussing above ☺
Yes, that seems fair, and also a hard puzzle.
>
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
[dns-privacy] please adopt draft-dkgjsal-dprive-unilateral-probing as a WG work item Re: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-02.txt
Daniel, Joey, On Thu, 2022-01-27 at 16:43 -0500, Daniel Kahn Gillmor wrote: > > ### Substantive changes from -01 to -02 > > - Clarify that deployment to a pool does not need to be strictly simultaneous > - Explain why authoritatives need to serve the same records regardless of SNI > - Defer to external, protocol-specific references for resource management > - Clarify that probed connections must not fail due to authentication failure > Thank you for this, this document is evolving very nicely. Speaking only for myself: some of the parts still seem too prescriptive to me (but I know I haven't been clear on what parts!). Examples: 4.3.1 seems too focused on some specific load balancer implementations, and causes a terrible combinatorial state explosion. 4.5 could perhaps use some words along the lines of "we describe an algorithm here; you could use another algorithm if it fits your implementation better, as long as it has similar outcomes". I do like that it mentions happy eyeballs without prescribing them. Speaking for both myself and Paul Hoffman: we are happier with your document than with our currently adopted work. We strongly suggest that the WG adopts unilateral-probing so we can work out what it would take to get some implementation work going. 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] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-02.txt
Hello Brian, many thanks for a completely worked-out protocol. Please find some comments below. A further reading of the document might yield more comments, but this is what I have now after my first reading. On Fri, 2021-09-17 at 20:48 -0700, Brian Dickson wrote: > Status: > https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/ > Html: > https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-02.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth > Diff: > https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-02 Quotes below are from the document. > NSECD New OPT RR N Signal desire for NSEC(3) for [RFC8198] I do not understand what this does that the DO bit does not already do. > Use of DS records [I-D.dickson-dnsop-ds-hack] for the protection of the > delegation to the authoritive name servers Of course, Ben's DSGLUE would work here too. The key differences between ds-hack vs. ds-glue appear to be: * hashing vs. verbatim * NS records only vs. flexibility (with NS/A/ and possibly TLSA as good starting points) I prefer DSGLUE, but as far as I can see it would be a drop-in replacement in your protocol. > Use of "glueless" zone(s) for name server names' zone > [I-D.dickson-dnsop-glueless] I see how this is a relevant part of how your setup fits together, but I don't like this requirement, and I believe using DSGLUE instead of ds-hack would remove this need, and allows dropping -glueless from the set of documents. > This would allow DNS caching to avoid repeated queries to the authoritative > server for the zone containing the DNS server names, to obtain the TLSA-type > information. This is not true for the example zone data given. The ns1-4 A/ records would prevent expansion of the wildcard for the TLSADOT record. The same problem appears with DNST in section 6.3.1. Given that, having DNST as an alias for SVCB, and TLSADOT as an alias for TLSA, seems mostly pointless to me. (That said, svcb-dns defining that '.' maps to _dns.ns1.example.com, not ns1.example.com, is very inconvenient to operators. The dot form is basically useless in svcb-dns. So, in that regard, I do like DNST.) > The value "Force" indicates the server should attempt to use ADoT, and return > a failure code of and an EDE value of if the authoritative server > does not offer ADoT, or any other ADoT failure occurs. 'the authoritative server' is too handwavy. Can 'Force' even work until all TLDs have encryption? I'm not sure I like section 8 at all. It feels like encoding policy at the wrong layer. Conclusion: ignoring TLSA for a moment, this protocol appears to be just a few changes away from my/Paul's proposal (if I generously include ds-glue-or-similar in that). It is very good to see this variant written out, so that it can be judged at its merits, which has been hard for various handwavy proposals only seen in messages in email threads. 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] scope of authoritative signalling [Was: Re: [Ext] Intermediate proposal (what I was saying at the mic)]
On Wed, 2021-08-25 at 19:05 -0700, Brian Dickson wrote: > If "foo.example" uses "NS ns1.dot-only.example.net", a query for > www.foo.example on port 53 can reasonably expect to get "REFUSED". This is not currently reasonable. If you want that to be reasonable, you have a bunch of RFCs to update. 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] DoQ Use Case Review
On Mon, 2021-08-16 at 08:18 -0400, Brian Haberman wrote: > https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/ > > We would like to hear comments/questions on the applicability of DoQ to > the three use cases described in the draft: > >1. Stub to recursive resolver >2. Recursive resolver to authoritative servers >3. Zone transfers > > Do you agree/disagree that the use cases should be considered for DoQ? agree > Do you agree/disagree that DoQ provides sufficient functionality for the > use cases? agree 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] [Errata Held for Document Update] RFC8932 (6629)
On Mon, 2021-07-05 at 09:33 -0400, Paul Wouters wrote: > > Perhaps instead of ephemeral/non-ephemeral, a fix would be: > > One example would be to replace all TCP/UDP port > numbers with one of two fixed values indicating whether the > original port was a system port (<=1024) or non-system port (>1024). system port (<1024) or non-system port (>=1024) 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] Fwd: New Version Notification for draft-schwartz-dprive-name-signal-00.txt
ll control over what is signalled for their servers. It can, of course, remove svcb--dotq.ns1.example.com from the example.com zone, but then anything delegated to that name just breaks. Proposal: allow resolvers to downgrade (in contradiction with the current second half of section 5). Then say: if svcb--t was ever signalled, the auth operator promises to at least send TCP RST for any connection attempt to port 853. Similar for DoH (443) and DoQ (the QUIC protocol has a CONNECTION REFUSED error code). This way, the downgrade in a resolver can be swift, instead of having to wait for timeouts. - Peter van Dijk & Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features
Hello DNSOP, On Wed, 2021-05-19 at 16:58 +, Paul Hoffman wrote: > Greetings again. Peter and I have revised > draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features > based on recent mailing list traffic. One major change is that we realized > that we could move even more sections from unauth-to-authoritative to > common-features because they would apply to the fully-authenticated use case. > Please review them to see if you agree. > > If people like the idea of us splitting out common features, it would be good > if it too became a WG document, particularly to help focus the discussions on > the unauthenticated and fully-authenticated use cases. > > --Paul Hoffman and Peter van Dijk > > https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt > https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-01.txt A friendly ping - we moved a bunch of text from our adopted draft to the 'common' draft, so that 'discovery' and 'security properties' can be discussed separately. We think this even makes sense if the adox draft does not get adopted today, because it (or some other draft with stronger security properties than our unauth draft) might get adopted in the future. So, chairs, can you please think about adopting draft-pp-dprive-common-features even before the adox draft is adopted? 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
[dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS
Hello DPRIVE! in the last two draft revisions of our protocol for unauthenticated encryption from resolvers to authoritatives, we adopted the SVCB discovery mechanism from draft-rescorla-dprive-adox-latest-00. This means that the two documents overlap somewhat, and there would be effort needed to keep the mechanisms in sync. To avoid that problem, instead we present here a separate document that contains the parts that the two protocols have in common. Our draft is adopted; we understand the authors of the authenticated draft intend to ask for adoption soon, as well. If the WG adopts this separate document, we will not have to keep the discovery bits in sync between the two, and we can hammer out the details of discovery once, in a single place. We imagine this would be much more efficient. - Paul & Peter Forwarded Message From: internet-dra...@ietf.org To: Paul Hoffman , Peter van Dijk < peter.van.d...@powerdns.com> Subject: [EXT] New Version Notification for draft-pp-dprive-common- features-00.txt Date: Sun, 02 May 2021 09:51:09 -0700 A new version of I-D, draft-pp-dprive-common-features-00.txt has been successfully submitted by Peter van Dijk and posted to the IETF repository. Name: draft-pp-dprive-common-features Revision: 00 Title: Common Features for Encrypted Recursive to Authoritative DNS Document date: 2021-05-02 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-pp-dprive-common-features-00.txt Status: https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/ Htmlized: https://datatracker.ietf.org/doc/html/draft-pp-dprive-common-features Htmlized: https://tools.ietf.org/html/draft-pp-dprive-common-features-00 Abstract: Encryption between recursive and authoritative DNS servers is currently being defined in two modes: unauthenticated and fully- authenticated. These two modes have some features in common, and this document defines those common features so that the documents defining the modes do not need to point to each other. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] How do we want to use draft-ietf-dprive-phase2-requirements?
On Tue, 2021-04-20 at 16:59 +, Paul Hoffman wrote: > On Apr 19, 2021, at 2:13 PM, Brian Haberman wrote: > > My question to the WG is how do we want to use this draft? I see > > four possible approaches, but I am sure someone will point out others. > > > > 1. Strictly requirements - these would be MUST-level functions that the > > WG determines have to be supported by any solutions draft. > > > > 2. Strictly design considerations - these would be functional areas that > > the WG determines need to be considered, but not necessarily included, > > by any solutions draft. > > > > 3. Requirements & design considerations - This is generally where the > > current draft sits IMO. > > > > 4. Drop the draft and let the solutions flow. > > As a document author, I prefer #4 but with a modification: every solution > document must have an honest, readable Security Considerations section that > covers the design considerations. By "honest", I mean that the text there > needs to have WG consensus, including of the people who have a different > preferred solution. > > My rationale for no longer needing a separate document is that the WG > discussion of adopting the opportunistic/unauthenticated draft, and the > possible adoption of the fully-authenticated draft, has pretty much fully > brought out all the requirements and design considerations for both > proposals. This makes sense to me. The explored solution space (which is way bigger than the viable solution space!) has covered so much ground, we've basically already seen it all. So, it is better to judge each proposal on its own, honestly stated indeed, merits (and demerits). 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
[dns-privacy] next steps for draft-opportunistic-adotq
Hello DPRIVE, First, a recap of my IETF110 presentation for those who missed it. I explained that the recent version of our opportunistic/unauthenticated draft (draft-ietf-dprive-opportunistic-adotq-01) included a rough skeleton of support for an authenticated use case, because no other proposal for that was alive at the time. Shortly after, another draft (draft-rescorla-dprive-adox-latest-00) describing an authenticated approach appeared. I suggested in my presentation that we take authentication out of our draft so that the two use cases (being 'unauthenticated' and 'authenticated') can progress side by side. draft-rescorla-dprive-adox-latest-00 proposes SVCB as a discovery mechanism instead of our TLSA, and this sounds good to us. The unauthenticated use case only needs discovery, so SVCB appears to be an even better fit than TLSA. SVCB also provides more protocol flexibility. Our proposal for a way forward: * We take authentication out of draft-ietf-dprive-opportunistic-adotq again. * We give the draft a somewhat more accurate name, as the switch to SVCB stops us being limited to DoT and DoQ (although I really do wonder if there is any appetite for DoH on the recursive<>auth path). * We let the drafts develop side by side, making sure they use similar wording where appropriate, and don't get in each other's way. Cheers, Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh
On Thu, 2021-03-18 at 13:29 +0100, Ondřej Surý wrote: > On 17. 03. 21 14:00, Brian Haberman wrote: > > All, > > This starts a DPRIVE WG call for adoption for > > draft-pauly-dprive-oblivious-doh > > (https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/). > > Please reply to the mailing list with your views (positive or negative) > > on the WG adopting the document and your supporting arguments. > > This call will end on March 31, 2021 at 11:59pm UTC. > > I also oppose adoption because of what Petr Špaček and Tomáš Křížek said. I also oppose adoption, for these reasons and many other reasons already given in the thread by others. 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] New draft on authenticated recursive <-> authoritative
On Wed, 2021-02-24 at 14:06 -0500, Paul Wouters wrote: > > It seemed the DS record idea stalled, because the authors didn't really > like the additional RTTs needed. You have been repeating that we actively refuse to deal with the additional RTTs. This is untrue and unfair to the point of rudeness. We have repeatedly stated being open to this child verification, if the WG had interest, but it did not - only you. Now repeating that claim again, and even stretching it to be the reason the draft stalled, is hard to explain other than as some confused arrogance. DOTPIN stalled because people, quite rightfully, did not like the idea of putting a pin for one NSset in the DS records for a million domains. All other concerns (such as deciding the exact level of protocol abuse DOTPIN is) are minor in comparison. A later informal proposal to make that the registry's problem ( https://mailarchive.ietf.org/arch/msg/dns-privacy/xOVfHOR6FFFPxsFqM8eB44J-Db0/ ) never made it into a draft, because at the time it did not seem like the right direction for the WG. 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] I-D Action: draft-ietf-dprive-xfr-over-tls-06.txt
On Thu, 2021-02-11 at 13:54 -0500, Tim Wicinski wrote: > Thanks Sara > > Folks should take a look at the changes, and those who raised issues can > ensure > these updates have addressed everything. This update works for me. Thanks! 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] Working Group Last Call for draft-ietf-dprive-xfr-over-tls
Hello Sara, On Fri, 2021-01-29 at 17:34 +, Sara Dickinson wrote: > To pick apart what exact changes would be needed to the document to support > these 2 relaxations explicitly for XFRs, it would include: > > CONNECTION RE-USE: > * Adding a reason to section 6.3.1 for not re-using an existing connection > something like: “as noted in RFC7766, separate connections for different > zones might be preferred for operational reasons. In this case the number of > concurrent connections for zone transfers SHOULD be limited to the total > number of zones transferred between the client and server.” > * If there is consensus the above is the right way to go, then since the main > goal of limiting the connections is to reduce load on the server, I would > also suggest adding some text to say “servers MAY limit the number of > concurrent connections accepted from a given secondary”. One concern is that > there is no easy way for the server to signal a preferred behaviour (for > example if it has a very large number of zones and a very large number of > secondaries it might really want to minimise connections), so I think this is > the best that can be done? > > > PIPELINING: > * Updates to sections 6, 6.1 and 6.2 and 6.3.2 to add an exception for XFRs > wrt pipelining. For section 6, this would be something like: > > “RFC7766 states that 'DNS clients SHOULD pipeline their queries’ on TCP > connections, however it did not distinguish between XFRs and other queries > for this behaviour. XFRs are not as latency sensitive as other queries, and > can be significantly more complex for clients to handle both because of the > large amount of state that must be kept and because there may be multiple > messages in the responses. For these reasons this requirement is relaxed for > XFR requests: clients sending XFRs MAY choose not to pipeline queries. > Clients that do not pipeline XFR queries, therefore, have no additional > requirements to handle out-of-order or intermingled responses as they will > never receive them. " > > Would that address your concerns? It would also be good to hear from other > folks if they agree with this balance. This works for us. Thank you very much! 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] Working Group Last Call for draft-ietf-dprive-xfr-over-tls
On Wed, 2021-01-27 at 21:35 +0100, Peter van Dijk wrote: > > > I'm not one of the authors, but re-reading the draft with "intermingling" > > in focus, I think the issues are: > > - The intermingling aspect originates in RFC5936 (over TCP) > > Several people have pointed that out to me - I totally missed that > since forever. 5936 specified the intermingling in a very loose way, > though. And just now it was pointed out to me that 7766, which updates 5936, has text like 'DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, ...' But, it also goes on to say 'certain primary/secondary configurations with many busy zones might need to use more than one TCP connection for zone transfers for operational reasons (for example, to support concurrent transfers of multiple zones).' and I feel the XoT document is taking that to the next level :-) 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] Working Group Last Call for draft-ietf-dprive-xfr-over-tls
Hi Brian, On Mon, 2021-01-25 at 10:28 -0800, Brian Dickson wrote: > > > > However, there's one part that bothers me. The 'intermingling' of multiple > > XFRs over a single connection (which is a SHOULD, not a MUST, so the > > document 'gets away with it', or conversely, implementations will get away > > with not implementing it) feels to me like a lot of additional code > > complexity for a gain that is not clear to me. XFRs are not latency > > sensitive to the point that TLS setup is an impediment. > > I'm not one of the authors, but re-reading the draft with "intermingling" in > focus, I think the issues are: > - The intermingling aspect originates in RFC5936 (over TCP) Several people have pointed that out to me - I totally missed that since forever. 5936 specified the intermingling in a very loose way, though. > - They want parity between TCP and XoT (which is reasonable) The document goes further than parity, by adding 'optimize the use of TCP connections and SHOULD ... edns-tcp-keepalive ... to manage persistent connections'. It also adds 'The number of TCP connections between a secondary and primary SHOULD be minimized (also see Section 6.4).' While I think reducing the number of connections is always good, this should be part of a good tradeoff in code complexity, and the risks of head of line blocking. (Of course, head of line blocking becomes much worse when the number of TCP connections is limited and intermingling does not happen. I do get where the document is coming from here.) > - Interoperability is assumed and not negotiated Indeed. > > In other words, I do not think the goal 'minimize the number of TCP > > connections between a primary and secondary' warrants the complexity of > > intermingling XFRs. I'd much rather have a few more TCP connections, a few > > more TLS states, and a much simpler code base. > > > > We (PowerDNS) do not think we will implement the parts of the draft that > > call for such code complexity, and thus, we will serialise XFRs (serial > > connection reuse does make sense to me) and/or in fact open multiple TLS > > connections (like we do with TCP today). At least in our code base, TLS > > setup would never be the bottleneck for transfers anyway. > > The relevant sections appear to be the text at the top of section 6.2, and > all of 6.3.2. > > Servers MUST be able to handle multiple XFR requests. > Clients MUST be able to handle intermingled responses. > However, Servers MAY intermingle, rather than must, on the responses. > > I concur with the code base complexity concern, particularly on the client > side. My worries are mostly split between the client and server side. > > I think this might be possible to accommodate with guidance (i.e. suggested > text to the following effect): > "NB: If clients do not want to support intermingled responses, a compliant > client could serialize requests to avoid multiple outstanding XFR requests. > If only one XFR is outstanding, no intermingling will ever occur." Indeed, the document allows this but it would be good to call out. > Similarly, server-side guidance could be added: > "NB: if servers do not want to implement intermingled responses, they can > serialize the full XFR responses to individual XFR requests, and this would > be compliant. Similarly, reordering of XFR responses versus XFR requests is > allowed but not required (in order to be compliant)." Indeed, that more clearly reduces the scope to 'servers do not close TCP connections after sending out a single XFR' (which is the most basic requirement currently specified in the document). > > Do any other vendors actually plan to implement such thorough connection > > reuse, with primaries actually intermingling multiple XFR responses over a > > single TCP/TLS session, and with secondaries actually firing off several > > XFR requests on a single connection to receive the zone chunks in whichever > > order they may come? > > It is not clear if our (internal) implementations will do so, or how > (intermingling out-of-order serialized-but-not-interleaved, versus fully > interleaving of multiple XFR responses). > > One possibility is the use of TLS proxies, which could multiplex multiple XFR > over TCP streams, such as from multiple TCP clients to multiple TCP servers, > across "shared" TLS XFR sessions (site to site). But that is conjecture only > at this point. Yes, but definitely possible. Such a proxy would need to be aware of DNS TCP framing, of course. 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] Working Group Last Call for draft-ietf-dprive-xfr-over-tls
Hello, On Thu, 2021-01-21 at 08:54 -0500, Tim Wicinski wrote: > This starts a Working Group Last Call for draft-ietf-dprive-xfr-over-tls > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ > > The Current Intended Status of this document is: Standards Track > > Please review the draft and offer relevant comments. I like most of the draft. Some of it seems 'obvious' but often 'obvious' differs from reader to reader, so it's good to be explicit about a lot of things. So, I'm not here to say 'all of this is so obvious that the draft does not need to exist at all'. However, there's one part that bothers me. The 'intermingling' of multiple XFRs over a single connection (which is a SHOULD, not a MUST, so the document 'gets away with it', or conversely, implementations will get away with not implementing it) feels to me like a lot of additional code complexity for a gain that is not clear to me. XFRs are not latency sensitive to the point that TLS setup is an impediment. In other words, I do not think the goal 'minimize the number of TCP connections between a primary and secondary' warrants the complexity of intermingling XFRs. I'd much rather have a few more TCP connections, a few more TLS states, and a much simpler code base. We (PowerDNS) do not think we will implement the parts of the draft that call for such code complexity, and thus, we will serialise XFRs (serial connection reuse does make sense to me) and/or in fact open multiple TLS connections (like we do with TCP today). At least in our code base, TLS setup would never be the bottleneck for transfers anyway. Do any other vendors actually plan to implement such thorough connection reuse, with primaries actually intermingling multiple XFR responses over a single TCP/TLS session, and with secondaries actually firing off several XFR requests on a single connection to receive the zone chunks in whichever order they may come? 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] DOTPIN, TLSA, and DiS
On Fri, 2020-11-20 at 12:14 -0800, Brian Dickson wrote: > > I think we (the three of us and maybe Tony Finch, if not the whole DNS > community) may be converging on a design that will, I believe, work. This is not the first time that design has been proposed. It is the first time it was not met with only criticism, however! > I just checked on something that was nagging at me: > Is there a way to secure the NS set without requiring the delegated zone to > be signed? > I believe the answer is "yes", at least assuming implementers follow RFC 4035 > correctly. > In section 5.2, the Nth paragraph reads: > " If the validator does not support any of the algorithms listed in an >authenticated DS RRset, then the resolver has no supported >authentication path leading from the parent to the child. The >resolver should treat this case as it would the case of an >authenticated NSEC RRset proving that no DS RRset exists, as >described above." > > So, using a new algorithm for whatever we do, should be 100% backward > compatible. > The assumption is any resolver supporting the new algorithm does so > correctly, and > that any resolver that does not support the new algorithm does the right > thing (treat like unsigned). In early 2019, Knot Resolver and 8.8.8.8 had trouble with this. They've both been fixed a long time ago now. < https://mailarchive.ietf.org/arch/msg/dns-privacy/HiqLSzeWRgwseOh6JiNBkScSq_o/ > > This means the design can be as simple as "put stuff in an apex DNSKEY record > with a new algorithm)", > plus put the corresponding DS (hash of DNSKEY elements that DS uses) in the > parent zone, is sufficient. > Note that for TLDs, the mechanism for this would be EPP sending of DS (or > DNSKEY), and/or using > the CDS/CDNSKEY mechanisms. Yes - I don't think the data functionally needs to even appear in the child's apex DNSKEY, it just needs a delivery mechanism into the parent. (In DiS, the delivery mechanism is "the parent's zone signer software"; that would just leave open the question of delivering the policy flag that Vladimir mentioned). 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] DOTPIN, TLSA, and DiS
On Fri, 2020-11-20 at 20:47 +0100, Vladimír Čunát wrote: > On 11/19/20 2:05 PM, Peter van Dijk wrote: > > 1. auth operators publish TLSA records for their NSes > > 2. the registry, while generating zone files, queries for those TLSA records > > 3. from the found TLSA records, the registry generates DOTPIN DSes > > 4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, > > and perhaps the DiS > > Intriguing but isn't it unnecessarily complicated? Yes, it is complicated. It is an exercise in ticking -all- the boxes (incremental deployment, low latency, scalable management) - by moving all the pain into the registry operation. > If we assume that > DiS-like is possible, I'd rather replace the DOTPIN-related parts by > some simple flag that tells if the zone's policy is to avoid cleartext. > > I.e., in comparison with today, the parent side would additionally sign: > (a) the NS set - e.g. via DiS; that's because signing certs directly has > those scalability issues > (b) and this "policy flag" in some way (say, yet another DS alg like > DiS, but there are other ways). Yes, I believe (and have said before) that this is how a TLSA-based deployment would make sense. > In retrospect I see that what I wrote is very similar to Manu's "Do9" > except for replacing WebPKI by TLSA, with all their pros and cons: > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 WebPKI has excellent latency properties compared to TLSA. In more words: a parent-side signal that does not pin keys, but does authenticate names, would allow WebPKI based DoT with zero extra queries compared to current non-DoT operations. 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
[dns-privacy] DOTPIN, TLSA, and DiS
Please bear with me while I take you on a rollercoaster :-) We introduce our three actors: DOTPIN: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ - pin TLS key material in a DS record. Scales badly if one NSset hosts 100k domains, basically preventing you from ever rolling keys. Written in the assumption that software changes at registries are hard, so it only asks them to allow one more DNSKEY Algorithm number. Has great latency properties. TLSA: frequently touted as an ADoT signal/pin mechanism that would not have all the problems DOTPIN has. Makes sense, but requires some inventive thinking because delegation NSsets are not signed. DiS: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/ - a parent side signature over delegation data (NS records and glue), published as another DS record. Written in the assumption that we can actually change registry software (in this case, specifically, the DNSSEC signer). We give our actors roles in a The Shining/MacGyver fanfic crossover: DiS assumes registry processes can be changed a little. If we trust that they can change more than just a little, the following combination of factors can be proposed: 1. auth operators publish TLSA records for their NSes 2. the registry, while generating zone files, queries for those TLSA records 3. from the found TLSA records, the registry generates DOTPIN DSes 4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, and perhaps the DiS This offers us: 1. TLSA-based keyrolls from a single 'source of truth' (the auth operator), at low delay (however often the registry re-lookups the TLSA and pushes a zonefile update) 2. a secure shortcut straight through the problematic unsigned nature of delegation NSsets 3. zero additional latency delivery of signal/pinning information to resolvers However: 1. the complex moving parts are now in the registry, instead of in 10-20 pieces of (mostly open source) DNS software 2. as a whole, it's not pretty 3. an operator hosting 100k domains can make the TLD zone file grow by 100k records by publishing one additional (TLSA) record for one of their NSes 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] how can we ADoT?
On Wed, 2020-11-18 at 23:09 +, Tony Finch wrote: > > > * Authenticate the server by `subjectAltName` `iPAddress`. [snip] > > > > For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending > > a server name at all (which matches what I said earlier - name servers > > have IPs, not really names). > > Do you mean not sending in TLS SNI? Yes, that would make sense if we're > not doing name-based auth. Yes. > > > * Ignore certificate name mismatches, and authenticate just the public > > > key. [snip] > > > > As above. (Not saying that it is the only way, but 'a name server has > > no name' has a lot of convenient properties.) > > There's another downside to this case: with IP-based or name-based auth, > you can put the CA's public key in the TLSA rather than the server key, so > there's less rollover churn, but that doesn't make sense for key-based > auth. Ah, of course. Then you have the downsides of TLSA with the downsides of DOTPIN. > I think there are significant (albeit woolly) advantages to staying as > close as possible to normal webPKI for DoT: much lower congnitive load for > operators who can reuse their https knowledge; deveopers don't have to > write code that's too weirdly different from https; very straightforward > parallel deployment for DoT, DoH, DoQ (if we ever want to support more > transports). That makes sense. 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] [Ext] Revised opportunistic encryption draft
On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote: > Peter van Dijk wrote: > > The incremental cost for a resolver (doing a full resolution process > > for the TLSA records of one or more NS names) is not small, and neither > > are the latency costs. For 'popular' name servers, this cost can mostly > > be amortised, leaving the penalty with any domain hosted on a NSset > > that only has a few domains. > > Yes. However I think the relative cost of TLSA lookups is much less when a > resolver implements delegation revalidation because then it's fetching > authoritative A and anyway, so it can fetch TLSA concurrently. > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/ As I understand the draft, the revalidation can happen in parallel to the actual query the user is waiting for. Any setup/discovery of secure transports would have to happen before that, so I'm not sure we can say 'on top of delegation revalidation, TLSA lookups are basically free'. > > > Using TLSA records at _853._tcp. in a signed zone provides an > > > unambiguous signal to use optionally TLSA, in a downgrade-resistant > > > manner. > > > > Not downgrade-resistant, until NS names in delegations become signed. > > Or until the parent nameservers support authenticated encrypted > transports. The design choice that DNSSEC did not make, a long time ago. > Even so I think delegations should be signed. It would solve a *lot* of problems. > A (the?) major issue with this whole ADoT effort is the bad trade-off > between a delegation-centric design (where the DoT signal is in the parent > zone) which has really formidable deployment obstacles, and really > troublesome scalability issues; or a DNS-hosting-provider-centric design > which has poor performance and downgrade weaknesses. I know DOTPIN has been rejected/shelved/not-adopted for the deployment/scalability reasons you mention, and also because the problem space was not mapped out well enough yet, but I still wonder if perhaps it makes sense to have two solutions to the DPRIVE charter - one with short paths, few extra queries (like DOTPIN), and one that works well with '500k domains delegated to one party' - with delegations signed, or a non-pinning signal (that does not take part in key rollovers) on the 500k domains, etc. > If (big if) we think it's worth upgrading the DNS delegation model (and > EPP, and all the registries and registrars, and all the IPAM databases and > user interfaces, and documentation and textbooks), can we also tackle the > scalability problem? By "scalability" I mean the need for a hosting > provider to update N delegations when a server cert changes. And there > are decades old problems keeping delegation NS and glue and DS records > correct. (A large chunk of the "it's always DNS" meme comes from how hard > it is to understand delegations and update them correctly.) This whole > area is a massive pain in the arse sorely in need of universal automation. +100. I've referred to this in other threads - if CloudFlare had gotten anywhere with their attempts to solve the operator / registrant / registrar / registry disconnect problem, all of this would be so much easier. > Any serious attempt at improving delegations needs to deal convincingly > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so > appallingly bad. Yes, or in the broader sense, my previous paragraph. 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] [Ext] Revised opportunistic encryption draft
On Wed, 2020-11-18 at 10:14 -0500, Paul Wouters wrote: > On Mon, 16 Nov 2020, Brian Dickson wrote: > > > Yes, this is a huge gap in the fundamentals for any privacy architecture > > (ADoT), which is rooted in the unsigned nature of > > NS records regardless of the security state of a delegation (DNSSEC or not). > > The IP connection to (small) nameservers will always leak information, > even if perfectly encrypted and obtained without privacy. Just by > connecting to say ns1.nohats.ca, any observer knows you are connecting > to either "nohats.ca" or "libreswan.org". But not what subdomain, if any, of those you are visiting. I do recognise that this is on the long tail of things we can try to protect. > The only way out of that is a distributed decentralized DNS cache. I always imagined that, given DNSSEC, we could bittorrent our way out of this. Then later people imagined we could blockchain our way out of this - but it hasn't happened yet. > > Downgrade resistant only if the delegation information is protected (NS > > names in particular). > > Protecting the delegation NS records against an on-path adversary (between > > resolver and TLD) does not have any nice > > solutions. > > This is basically the same problem as ESNI. Except ESNI fixed it by > pulling information from (encrypted) DNS :) That's "protecting the NS records against snooping", if I understand you correctly. The other problem is protecting the delegation NS records against meddling, for which various partial solutions have been provided but we have zero standardised today. 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] how can we ADoT?
On Tue, 2020-11-17 at 01:21 +, Tony Finch wrote: > Thanks for reading and providing feedback! > > Peter van Dijk wrote: > > > On Wed, 2020-11-11 at 19:07 +, Tony Finch wrote: > > > * Encryption would apply to the server as a whole, whereas the > > > working group consensus is that it should be possible for > > > different zones on the same server to use encrypted and > > > unencrypted transports. > > > > (plus, in another email, Tony wrote: "A nice thing about TLSA records > > is they also tell the client what name to look for in the server's > > cert.") > > > > This looks like a mistake to me, or at least, a choice that would have > > to be made very deliberately. > > My point above mostly relates to section 5.1 points 7 and 9 of > https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02 I strongly believe point 9 should be removed, for reasons articulated in my previous email briefly quoted above :) > It also seems that any 'split' between which zones on a certain IP > > support encryption and which zones do not, would make any opportunistic > > proposal obsolete immediately. > > I'm not sure what you mean here because "opportunistic" has multiple > meanings, and they have different implications for how a client might > authenticate a server. Opportunistic is, perhaps deliberately, vaguely defined. What I think I mean to say there is 'if an auth NS responds on port 853, it had better offer me all the data it also has to offer on 53'. > ... and now the text below ... > > > ## TLS certificate authentication > > * Authenticate the server by `subjectAltName` `iPAddress`. Unfortunately > IP address certificates are hard to obtain (though this is likely to > become easier after [RFC 8738] is deployed). This is only an advantage > when there is no signal associated with the nameserver's name (such as > TLSA records) indicating support for encrypted transports, because if > there is such a signal the client knows what name to expect in the > certificate. For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending a server name at all (which matches what I said earlier - name servers have IPs, not really names). > * Ignore certificate name mismatches, and authenticate just the public > key. This raises the question of how the client can find out the right > public key: if it can find out the right key why can't it also > find out the right name? It has the disadvantage that public key > pinning has a poor operational track record. As above. (Not saying that it is the only way, but 'a name server has no name' has a lot of convenient properties.) > * Use the presence of a DNS record associated with the nameserver name > to indicate that the server's certificate will match the name. For > example, TLSA records alongside the nameserver's address records; > other possible kinds of records for doing this job are discussed in > the following subsections. First thought: yes. Second thought: what if the owner of the 'vanity name' 'aliased' to the NS just copies the TLSAs? At sufficient deployment, the failure mode is immediate and clear, of course. > * A nameserver's official name, which is used in the vast majority of NS > records pointing at this server. The presence or absence of a TLSA > record associated with this name controls whether transport encryption > is used for the owners of these NS records. Makes sense, that's what puts the NS owner in control of transport, instead of (or together with) the zone owner. > * Alternative names that advertise different encrypted transports than > the official name. A nameserver operator can use different names for > the same nameserver to support encryption for a subset of zones. This > might be useful for testing or phased rollout. This is neat. > A nameserver should > serve the same zones over encrypted transports that it serves over the > corresponding UDP and TCP transports. Yes! > [This slightly weird phrasing is to avoid ruling out features like views > or split horizons.] Cleverly boxed. 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] [Ext] Revised opportunistic encryption draft
//tools.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt Both of these make room for non-hashing variants of 'authenticate data that is unsigned today'. :-) (If you'd like to have more puzzle pieces, https://github.com/PowerDNS/parent-signals-dot has some additional semi-rambly thoughts in the area, although most of it has made it into conversations on DPRIVE and DNSOP meanwhile). 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] [Ext] Revised opportunistic encryption draft
On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote: > > > > Using TLSA records at _853._tcp. in a signed zone provides an > > > unambiguous signal to use optionally TLSA, in a downgrade-resistant > > > manner. > > > > Not downgrade-resistant, until NS names in delegations become signed. > > That's a moot point. > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC 6698 > section 4.1 (Determining whether a TLSA RRSet can be used MUST be based on the >DNSSEC validation state (as defined in [RFC4033]). Which buys you very little if the name you are looking up is from an unauthenticated source - like NS names in delegations. > So, downgrade-resistant, period. No. 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] how can we ADoT?
On Wed, 2020-11-11 at 19:07 +, Tony Finch wrote: > > * Encryption would apply to the server as a whole, whereas the > working group consensus is that it should be possible for > different zones on the same server to use encrypted and > unencrypted transports. (plus, in another email, Tony wrote: "A nice thing about TLSA records is they also tell the client what name to look for in the server's cert.") This looks like a mistake to me, or at least, a choice that would have to be made very deliberately. Today, the name through which I reach an NS does not matter - it is not part of the protocol exchange like the HTTP Host header is. This simplifies a lot of things, and allows some leeway for mismatches in names between parents, childs, etc., as long as they reach the same IP. It also seems that any 'split' between which zones on a certain IP support encryption and which zones do not, would make any opportunistic proposal obsolete immediately. I'd like to assume that all transports offered by an NS host the ~same data (ignoring, for a moment, that we might one day imagine data that should only be seen over transports with certain security properties, but I'm imagining that such data would not cover whole zones). In fact, it would be good if I don't assume. Instead, we should actively decide whether any such splits are allowed, or forbidden. I note that the phase2 doc has this text: 9. A given name server may be authoritative for multiple zones. As such, a name server MAY support use of a secure transport protocol for one zone, but not for another. So in fact, right now we have written down that this is allowed. But I think it is a mistake. 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] [Ext] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt
On Sun, 2020-11-15 at 16:52 +, Paul Hoffman wrote: > Thanks for the response! I hope that there is more list discussion before the > WG meeting this week. > > On Nov 15, 2020, at 5:52 AM, Peter van Dijk > wrote: > > The cost of port checking is not low. > > We disagree in the general case, because I'm assuming a transport cache that > is filled before an actual query is sent. Transport caches would be useful > for both opportunistic and authenticated encryption. That makes sense, but there's a risk of penalizing the 'small domain owner' here. > We agree in the specific case of "determine the transport at the time the > resolver's user is waiting for an answer". +1 > > Variant 1: try 853 and 53 in parallel. High code complexity and a high > > likelihood that the first query to a 'new' auth (where 'new' might be > > measured in minutes) will be plain text anyway. > > There is no code complexity if you are probing the fill a transport cache. > There is definitely the large, classical complexity of asyncy-with-abort for > determining when needed. > > > Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms > > is a long time. > > For cache-filling, a 500 or 1000 ms timeout seems reasonable. For immediate > need, there is no way to sanely balance "additional privacy" against > "addition latency" in a way that everyone (or even most people) would agree > to. Agreed. It's a big spectrum from DOTPIN (~no additional latency, lots of privacy, but some serious deployment impediments) to some interpretation of 'just do TLSA' (lots of additional latency) and any other proposal is likely to fall somewhere on that spectrum, with some room to be even worse than TLSA. Anything involving potential timeouts does look bad from the start, to me. > > This is not happy eyeballs where both transports (v4 and v6) tend to have > > identical security properties. > > Exactly right. > > > DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing > > and guessing in the resolver process. I'd love for us to not add probing > > and guessing in other parts of that process. > > I would love for that as well, if we make the solution barely harder to > implement than port-checking. I am skeptical that we as a group can make a > simple solution because everything we as a group do ends up much more > complicated than we expected when we started. We are terrible people :-) > This is why I think we should compare the result to port-checking. It is a useful baseline for comparison, indeed. > The interesting wrinkle here is that if the solution is DNS-based, it will > very likely be faster than port-checking because in most cases the result > will come back much faster than any timeout that someone would pick for > port-checking. The answer will likely also have much more value than a port > check. That gives us (at least) two axes to compare and argue about, so I > think it is worth pursuing. Tony's draft has a lot of good comparison > thinking in it already. Yes. 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] [Ext] Revised opportunistic encryption draft
On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote: > The most unambiguous signal possible, is the presence of a TLSA record on > _853._tcp.. That's quite a far reaching statement, and I believe it likely to be wrong. > Using NS names in a separate zone or zones (for each DNS operator) is > scalable, and facilitates DNSSEC signing, at little to no incremental cost > and little to no operational complexity The incremental cost for a resolver (doing a full resolution process for the TLSA records of one or more NS names) is not small, and neither are the latency costs. For 'popular' name servers, this cost can mostly be amortised, leaving the penalty with any domain hosted on a NSset that only has a few domains. > Using TLSA records at _853._tcp. in a signed zone provides an > unambiguous signal to use optionally TLSA, in a downgrade-resistant manner. Not downgrade-resistant, until NS names in delegations become signed. (I proposed some solutions for that in other threads; Fujiwara has [independently, I think] now written a draft resembling one of those solutions https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1 ) 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] [Ext] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt
On Wed, 2020-11-04 at 15:04 +, Paul Hoffman wrote: > It would be useful if a resolver could tell in advance, and at a cost less > than port-checking. There could be a new protocols developed to do that. I > don't see this as a requirement, though, given the low cost of port-checking. The cost of port checking is not low. Variant 1: try 853 and 53 in parallel. High code complexity and a high likelihood that the first query to a 'new' auth (where 'new' might be measured in minutes) will be plain text anyway. Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms is a long time. This is not happy eyeballs where both transports (v4 and v6) tend to have identical security properties. DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing and guessing in the resolver process. I'd love for us to not add probing and guessing in other parts of that process. 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] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)
On Wed, 2020-08-12 at 12:51 +0200, Peter van Dijk wrote: > Delegation NS records are not signed, so do we stick -those- (or a hash > of the NSset perhaps?) into DS? https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1 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 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
[dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)
(I changed the subject because this has turned into a solution conversation, instead of a use case conversation) On Tue, 2020-08-11 at 21:49 -0400, Paul Wouters wrote: > On Mon, 10 Aug 2020, Peter van Dijk wrote: > > > On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote: > > > In the case of encrypted DNS to authoritative servers, those servers > > > obviously can have an cryptographic ID based on FQDN. > > > > This is not obvious. It would be great if it was; but it isn't. > > Sorry, I did not realise it was not obvious to everyone, so let me > clarify: > > _853._dot.ns0.nohats.ca. IN TLSA > _443._doh.ns0.nohats.ca. IN TLSA Yes, that part seems obvious (if we assume the records live with the child, which I guess is obvious from your 'national MITM' argument in other threads). Many other aspects are not obvious. Some examples follow. Delegation NS records are not signed, so do we stick -those- (or a hash of the NSset perhaps?) into DS? Can we find those TLSA records without leaking the names of the name servers we are looking for, or do we decide that name server names are not a privacy leak? Do we move delegation-revalidation from 'possibly later' to 'always do that first', so that we get signed NS records before we look for TLSA? Do we expect resolvers to issue a couple of TLSA queries per NS before getting to the actual end user's question? 'Put TLSA records in your zone' is not a protocol. I'm sure we can define a protocol that revolves around TLSA, but your description is not yet it. That is what I mean by 'this is not obvious'. > This uses the unique FQDN of each nameserver's name. You can have > multiple TLSA records if you use different keys on some of your > nameservers (eg some outsourced to an ANYcloud provider) Assuming you use vanity names in the outsourcing (i.e. ns5.nohats.ca is actually a CloudFlare name server). If you don't use vanity names, the scaling mentioned just below comes for free because the outsourced operator would own the TLSA records (i.e. nohats.ca IN NS paul.cloudflare.com). > Note that this scales with the nameserver. For example by publishing the > above, the libreswan.org domain would also have dot/doh published as it > is using the same nameservers. This, to me, is the main selling point of tying key publication to NS names instead of zone names. 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] Possible use case: Opportunistic encryption for recursive to authoritative
On Fri, 2020-08-07 at 19:12 -0700, Rob Sayre wrote: > The issue is that connection establishment will be expensive, which is > something separate from getting a bunch of queries. As others have pointed > out, this cost will be amortized to almost nothing most of the time. After an > outage, this connection establishment cost will have to be dealt with in > parallel. > > I don't have an opinion on whether this should be implementation guidance, or > even in the spec. In the DS pinning draft, we explicitly decided to leave this out of scope, as we wouldn't want to prescribe resolver behaviour for other discovery methods (such as opportunistic). Sensible handling of connection establishment and pooling feels like a separate topic to me, so I don't think it should be part of any discovery document. I am unsure it should be an IETF spec at all. 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] Possible use case: Opportunistic encryption for recursive to authoritative
On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote: > > In the case of encrypted DNS to authoritative servers, those servers > obviously can have an cryptographic ID based on FQDN. This is not obvious. It would be great if it was; but it isn't. 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] Registry framework for draft-ietf-dprive-early-data
On Thu, 2020-07-30 at 02:58 +0100, Tony Finch wrote: > Ilari Liusvaara wrote: > > Then there is RRSIG, which seems bit alarming. While direct queries > > should not do anything special, I noticed two troublesome properties: > > > > 1) The answers can be pretty large (amplification hazard with UDP). > > 2) The queries can be really slow compared to other types. > > Yes. From an implementation perspective, RRSIG queries work in a very > similar way to ANY queries. They have the advantage that no-one is likely > to think an RRSIG query is useful, so it's reasonable to NOTIMP them. > If QTYPE=ANY is forbidden for early data then QTYPE=RRSIG should be too. NOTIMP tells the client 'I do not support the QUERY opcode'. That is not a message you want to send out, unless you want people to just stop querying you. (PowerDNS has picked REFUSED as the response to RRSIG queries). 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] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt]
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 a
Re: [dns-privacy] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt]
Hi Duane, On Tue, 2020-07-14 at 22:13 +, Wessels, Duane wrote: > Hi Peter, > > While I remain neutral as to whether or not ds-dot-signal-and-pin is a good > idea overall, you can count me as one that thinks flags=257 is a bad idea. I > don't think anything in 403[345] say that flags can be interpreted > differently depending on the algorithm or on the value of the Zone Signing > column. I agree, there is no 'legal' basis there, and our document aims to avoid needing any new legal basis (or, rephrased, we aim to avoid updating any existing RFCs if we can). I wanted to put 257 in -01 exactly to get some more feedback on the choices we have there. An informal small scale survey around a few registrars with extensive experience in a lot of TLDs suggested that 0 would not go over well, but we don't actually have a lot of data. (We are collecting data at https://github.com/PowerDNS/parent-signals-dot/issues/22 if anybody wants to chime in with more facts). I would also much prefer flags=0. > The document uses the phrase "DNSKEY algorithm" very often but I think you > really mean DNS Security Algorithm (or just algorithm). For example, > >more than one DS record with DNSKEY algorithm TBD > > is better as just > >more than one DS record with algorithm TBD Thanks! We've noted this at https://github.com/PowerDNS/parent-signals-dot/issues/37 and will improve the wording for -02. 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
[dns-privacy] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt]
Hello, please find below revision -01 of our proposal for enabling DoT from resolver to authoritative. New in this revision: * a lot of clarifying text without changing the underlying protocol * the DNSKEY flags field is now specified to be 257 instead of 0. We know that this goes against the explicit wishes of some of those who commented on -00, but we argue in the document that because our algo TBD will have 'Zone Signing=N' in the IANA DNSKEY algo registry, the flags do not mean 'ZONE' and 'SEP'. The value 257, meanwhile, is believed to go down with registries much easier. * 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 Furthermore, we have tried to do a review of this protocol against the requirements of the DPRIVE phase 2 document. You can find this review (which might be updated outside of revisions of this draft or the phase 2 draft) via https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin/yardsticks We'll be presenting the draft at the IETF108 dprive session. Kind regards, Manu, Robin & Peter Forwarded Message From: internet-dra...@ietf.org To: Robin Geuze , Peter van Dijk < peter.van.d...@powerdns.com>, Emmanuel Bretelle Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds- dot-signal-and-pin-01.txt Date: Mon, 13 Jul 2020 01:47:10 -0700 A new version of I-D, draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt has been successfully submitted by Peter van Dijk and posted to the IETF repository. Name: draft-vandijk-dprive-ds-dot-signal-and-pin Revision: 01 Title: Signalling Authoritative DoT support in DS records, with key pinning Document date: 2020-07-13 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt Status: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ Htmlized: https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-vandijk-dprive-ds-dot-signal-and-pin Diff: https://www.ietf.org/rfcdiff?url2=draft-vandijk-dprive-ds-dot-signal-and-pin-01 Abstract: This document specifies a way to signal the usage of DoT, and the pinned keys for that DoT usage, in authoritative servers. This signal lives on the parent side of delegations, in DS records. To ensure easy deployment, the signal is defined in terms of (C)DNSKEY. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
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
Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Hi Shumon, On Tue, 2020-06-09 at 12:37 -0400, Shumon Huque wrote: > I think TLSA in the child zone could be made to work though, so I think it's > still worth thinking about some more. Here's my suggestion: > > Place the TLSA record at the zone name, i.e. at the apex of the child zone, > rather > than at the NS server names: _853._tcp.example.com/IN/TLSA. > > That solves the name authentication problem because the nameserver names > aren't authenticated in the referral, but the zone name is authenticated via > the > signed DS RRset. What SNI do you then use when connecting to a name server? > The initial bootstrapping problem can be addressed by using the TLS > DNSSEC chain extension, which can deliver the zone's TLSA > RRset on first contact, in-band in the TLS handshake. You mention the > possibility of "stuffing the TLSA chain in TLS" - I wanted to make sure > you knew the design work for this mechanism is already done: > >https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-01 I know that that is exactly what Robin referred to :) > Using the TLSA RR means that we can now support the full semantics > of TLSA: EE cert, auth, local TA issued cert, or PKIX/WebPKI constraints. No, because you don't know the name server names with certainty, so you're still limited to pinning the key, the last cert in the chain, or using a private CA. WebPKI most certainly is out, because ns.attacker.org could also get a cert from the same public CA. 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Hello Christian, On Sat, 2020-05-30 at 23:00 -0700, Christian Huitema wrote: > I am wondering how using the signalling that you propose affects > experimentation with DoQ? I assume that with your proposal, we could > either have several DS records with different "algorithm" values, or a > single record with a flag somewhere stating that both TCP/DoT and > UDP/DoQ are supported. Have you thought about that? We have definitely thought about that! The way this signaling protocol is structured means that we cannot see DNSKEY flags until we have established some encrypted connection (in our case, DoT). So flags are out. I think it would be simplest to allocate one 'algorithm' number per protocol. This would also allow protocols other than DoT to perhaps use the various DNSKEY/DS fields for different semantics. 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Fri, 2020-05-29 at 11:59 -0400, Paul Wouters wrote: > On Fri, 29 May 2020, Peter van Dijk wrote: > > > > - Takes DNSKEY, only does syntax checks ---> we dont need to publish > > > anything > > > > Yes. > > Actually I was wrong. We still need to publish something so the child > proves the parent was not maliciously publishing a DS record. So we > would probably publish it as a CDS to keep it out of the DNSSEC > validation path and make it easy to compare parent DS to client CDS. I know you have spent a lot more time thinking about attacks from a parent to a child zone, so I'm probably missing something that's obvious to you. I'm not even sure what my question is, so let's try this: if a malicious parent has the ability to publish a malicious DS record, why wouldn't that parent also change the NS records in some subtle way? Then the real client side CDS becomes invisible. I have trouble seeing a specific combination of attacker choices that makes sense here. > > > - Takes DNSKEY, but verifies it is a supported algorithm --> we have to > > > convince them to support our pseudo alg > > > > Yes, and, we found out and will put in -01: to allow 'weird' flags for > > at least that algo. > > See my other email about DNSKEY algo 253 and 254. Since that's in the RFC, > you will have a better case arguing they have to support those. Assuming we (our draft, or some loosely related variant like the couple of other proposals in this thread) get to RFC, IANA will assign a number (or perhaps even before that). I'm not worried about getting the algo number on the registries' allowlist.. eventually. (see my reply to the other email, that I had missed before, for why I think 253/254 are not appropriate) 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Fri, 2020-05-29 at 11:31 -0400, Paul Wouters wrote: > > Note for DNSKEY algorithm, we could use 253 or 254: > > https://tools.ietf.org/html/rfc4034#appendix-A.1.1 > > DNS software might already support ignoring these algorithms without > adding too much noise to the DNSSEC validation process of having > "wrong" DNSKEY's. PowerDNS does nothing specific for those numbers. A quick grep of the Unbound codebase suggests the same there. I wouldn't expect any noise from unknown algorithms - have you seen otherwise? Furthermore, 253 and 254 are specifically targeted at people/organisations/groups that do not want/cannot afford/... an IANA registration. In other words, people that don't want to go through the RFC process. I don't think that's the path we want to be going down here :) 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Fri, 2020-05-29 at 11:25 -0400, Paul Wouters wrote: > On Fri, 29 May 2020, Peter van Dijk wrote: > > > On Wed, 2020-05-27 at 21:27 -0400, Paul Wouters wrote: > > > It would make everything a LOT cleaner and we got no bogus > > > DNSKEY records to ignore in our DNSSEC validation path. > > > > What bogus DNSKEY records? > > It really all depends on what registry systems you want to support. Right! Preferably as many as possible - that's why the process in the draft looks more convoluted than would be desirable. Note that the DNSSEC validation paths in existing resolvers already ignore DNSKEYs for algos they do not support. > We have some combo's: Thanks, I'm going to go through them one by one just in case you spotted any interesting edge cases. > - Takes any DS--> give our DS with DoT info embedded Right, easy. > - Takes DS, but verifies it is a real DNSKEY at the child --> we create bogus > DNSKEY matching our DS request I am hoping, also for 'normal' DNSSEC reasons (like key rolls) that no registry does this. > - Takes any CDS --> Put our info in zone as CDS Yes. > - Takes CDS, but verifies it is a real DNSKEY at the child --> we create > bogus DNSKEY matching our CDS request Hopefully as above. > - Takes DNSKEY, only does syntax checks ---> we dont need to publish anything Yes. > - Takes DNSKEY, verifies it lives in child ---> we create bogus DNSKEY Hopefully as above. > - Takes DNSKEY, but verifies it is a supported algorithm --> we have to > convince them to support our pseudo alg Yes, and, we found out and will put in -01: to allow 'weird' flags for at least that algo. (Incidentally you might one day run into the same question with DELEGATION_ONLY, although a zone delegated from a registry would not be a common place for that flag) > - Takes any CDNSKEY ---> we only need to publish as CDNSKEY, not DNSKEY Yes. > - Takes CDNSKEY but verifies it lives in child as DNSKEY ---> we need to > publish CDNSKEY and bogus DNSKEY Hopefully as above, again :) I'm collecting registry issues at https://github.com/PowerDNS/parent-signals-dot/issues/22 - I hope that list never grows a 'demands visible DNSKEY to go with the DS' entry! > When I say bogus I mean "not a DNSKEY used for DNSSEC validation of DNS data" Understood now. I think 'bogus' might be the worst possible choice of words though ;) 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Thu, 2020-05-28 at 12:08 -0400, Paul Wouters wrote: > On Thu, 28 May 2020, Petr Špaček wrote: > > With your proposal auth server operators need to _also_ operate DNS > > resolver and tie it together with the auth server. That's very significant > > change from how authoritative servers are operated today. > > That change is pretty minor compared to to including a whole TLS stack in > a DNS Auth server. Which btw, you could also do with a different program, > to minimize the traditional auth nameserver code. > > Compared to hacking all code at nameservers and registries for mangling > and unmangled DNSKEY records, I think that is a very reasonable trade > of. The DNSKEY mangling in a resolver is 10-20 lines of code - I doubt tls-dnssec-chain can be done in less? There is no mangling at registries, they convert DNSKEY to DS like they do for any existing DNSKEY algorithm. 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote: > Peter van Dijk wrote: > > On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote: > > > 1. Bit 7 of the Flags fields needs to be 0. > > > > Definitely [...] I noted earlier that whatever flags we might need, it's > > definitely *not* ZONE and SEP. > > > > > 2. This needs a new Protocol number > > > > I understand why you would say that, but I'd love to avoid doing that. > > I wonder how much 'IETF' pain specifying another protocol number would > > be, but what worries me more, ironically, is how it changes the format > > away from normal DNSSEC. The draft was written such that a lot of > > existing software needs no changes at all - I don't know if changing > > the protocol number is compatible with that goal. > > This made me wonder if this pseudorecord should be a KEY instead, and then > I wondered how hard it would be to persuade existing code to generate a DS > from a KEY. That could make semantic sense, but would muddle the connection to 'DNSKEY in EPP' and 'CDNSKEY sync from child to parent'; I think it would add more confusion than the semantic correctness is worth. > But anyway, this signalling and verification scheme sounds clever and neat. Thanks! 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Hello Ben,
On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote:
> I like the idea of signalling DoT support in the DS record, but I worry a bit
> about putting the SPKI fingerprint in the DS as well. Having to update the
> parent zone whenever the TLSA key needs to be rotated seems cumbersome and
> fragile, especially if the nameserver is operated by a third party.
I agree, it's the weakest link in the proposition.
> DoT authoritatives would need to keep both the old and new certificates on
> hand during the transition
keys, not certificates
> , and DoT recursives would need some way to signal in the ClientHello which
> one they are expecting.
I don't follow - if the DS set has both the old and new keys, the DoT recursive
will accept either. I ki
> This is pretty far from how TLS normally works.
Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm missing
something.
> I wonder if you considered using draft-ietf-tls-dnssec-chain-extension
> instead? That would provide the same security and performance, using less
> volatile information in the parent. Specifically, I think that the DS record
> would have to convey one bit ("DoT enabled") plus the name of the nameserver
> (which should probably match the NS record). That seems preferable to me.
I considered putting names in DS records; I also considered chain-extension;
but I failed to consider them together! With NS names 'verified' by DS, that
looks like something that would also be secure. I agree with the problems Petr
spotted - I'm aware of roughly zero implementations of dnssec-chain in clients
or servers.
> That seems preferable to me.
For me, with 10 domains on two name servers, not having the complexity of
chain-extension is preferable. For others, with a million domains, obviously
our draft does not scale. I've been assuming we'd end up with two or three
separate signals, each fit for purpose for a certain scale. Your proposal seems
like a viable candidate to be one of those to me.
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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote: > I thought using keytag 0, which cannot happen normally, would allow > you to leave algorithm and other values more real. This comment made me curious. Why would that be true? So I generated 524726 keys equally split between algorithms 8, 13, and 15. The result: 2 algo 13 keys with tag 0, 7 algo 15 keys with tag 0. I've pasted them at https://gist.github.com/Habbie/feb0bf288ea1137bee5a2c3d8913ba7f (happy to provide the related private keys if anybody cares). None for RSA, though, which I bet was predicted in the work behind https://indico.dns-oarc.net/event/22/contributions/315/attachments/316/555/Quest_for_the_missing_keytags.pdf and https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Tue, 2020-05-26 at 09:40 -0400, Paul Wouters wrote: > I thought my initial reading this was stored inside a DNSKEY was wrong > and things are actually stored in a DS digest. And DS records do not > have flags of the DNSKEY, so why are we talking again about DNSKEY > flags? When I ask my resolver for TXT validpin.dotpin.powerdns.club., the following things happen in the resolver: Queries are issued to root, TLD, etc., until the delegation to validpin.dotpin.powerdns.club from dotpin.powerdns.club is received. It looks like this: validpin.dotpin.powerdns.club. NS pdns-public-ns1.powerdns.com. validpin.dotpin.powerdns.club. NS pdns-public-ns2.powerdns.com. validpin.dotpin.powerdns.club. DS 17418 225 2 validpin.dotpin.powerdns.club. IN RRSIG DS In this test deployment, we have chosen algorithm number 225 by fair dice roll. The resolver connects to a NS, let's say pdns-public-ns1.powerdns.com, on port 853. During the handshake, the resolver receives the SubjectPublicKeyInfo from the name server. The resolver then constructs, in memory, a DNSKEY: pdns-public-ns1.powerdns.com. DNSKEY 0 3 225 [base64-encoded SPKI] The resolver then turns this into a DS with the normal procedure for DNSKEYs (https://tools.ietf.org/html/rfc4034#section-5.1.4). This yields a DS with some keytag, algo number 225, and digest type 2 (because that's what we saw in the DS set). The resolver checks if the resulting DS is in the DS set given by the parent. If so, we are now connected securely. If not, we disconnect and do not use this name server. > I dont know what you will use for keytag. https://tools.ietf.org/html/rfc4034#appendix-B > The digest type would also be some strange number meaning > "not really a DNSKEY digest". The digest type is one of the types from https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml, just as with normal DNSKEY processing. > So why talk about DNSKEY flags? Where do these appear in the proposal? The proposal currently has no need for any flags, so the flags field is set to zero. If we come up with convincing reasons for flags, we could define some. > Why make life harder > by needing to stuff square things into round boxes twice instead of > once? Because many registries only accept DNSKEY (via EPP or as CDNSKEY), and insist on doing the digesting into a DS on their end. 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Hello Ondřej, On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote: > >Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, > >then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's > >owner name MUST be the name of a zone. If bit 7 has value 0, then > >the DNSKEY record holds some other type of DNS public key and MUST > >NOT be used to verify RRSIGs that cover RRsets. > > and also: > > >The DNSKEY RR is not intended as a record for storing arbitrary > >public keys and MUST NOT be used to store certificates or public keys > >that do not directly relate to the DNS infrastructure. > > So, while my first though was same as Paul’s - this is abuse… I came to > conclusion, it actually isn’t. > > That said - I think this needs some modifications: > > 1. Bit 7 of the Flags fields needs to be 0. Definitely - it is not explicit but the examples in draft -00, and the PoC code, all use 0 for the flags. In https://github.com/PowerDNS/parent-signals-dot/issues/20 I noted earlier that whatever flags we might need, it's definitely *not* ZONE and SEP. > 2. This needs a new Protocol number I understand why you would say that, but I'd love to avoid doing that. I wonder how much 'IETF' pain specifying another protocol number would be, but what worries me more, ironically, is how it changes the format away from normal DNSSEC. The draft was written such that a lot of existing software needs no changes at all - I don't know if changing the protocol number is compatible with that goal. > 3. And since we now have non-„DNS zone key“ with a different protocol we > might get a separate IANA registry for the algorithms (if needed). We liked this, until we realised it will be painful with DS records. Because the protocol number is not visible in the DS records, a 'pin signal algo 8' and 'DNSSEC RSASHA256' DS are indistuingishible from eachother. While validators should accept this, it will make tools like dnsviz very hard to use if assignments between the existing and this new registry overlap. So, we'd have to state that the two registries may not issue overlapping assignments, in which case we might as well stick with the one registry we have. 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote:
> On Sun, 24 May 2020, Peter van Dijk wrote:
> > The draft says 'The pseudo DNSKEY record MUST NOT be present in the
> > zone.' What can we add to the text to make it clear that no query is
> > sent to the zone's name servers -until- their TLS key has been
> > verified?
>
> You confused me with "pseudo DNSKEY record". You meant to say "pseudo DS
> record".
We chose that language because the DS record is a very real thing that
exists in the parent zone - but it is hashed from a DNSKEY record that
only exists in the memory of the resolver, and of the tooling that
sends the DNSKEY to the parent (via EPP, CDNSKEY, etc.). That's how we
meant the word 'pseudo'. We have thought about different terminology
for it, and clearly we were right to doubt ourselves about the wording.
I don't think 'pseudo DS records' covers what we are doing in, but I'm
open to suggestions for better wording.
> Now it makes more sense that our suggestions are a lot more
> similar then I originally understood.
That makes me very happy! This will make discussion a lot easier.
> The draft currently has:
>
> The pseudo DNSKEY record MUST contain Base64 encoded [...]
That phrasing focuses on presentation format - the resolver code
wouldn't actually involve Base64.
This code from a dig-like tool adapted to the draft does not use Base64
anywhere, and the same would apply to the actual resolver process:
(handler is a TLS connection object that has connected to the remote
853 port, and performed a TLS handshake without any certificate/key
checking)
DNSKEYRecordContent drc;
drc.d_algorithm = dotpinalg;
drc.d_key = handler.getPeerPubKey(); // DER, no base64 involved
drc.d_protocol = 3;
cerr< dsset;
auto ret = stubDoResolve(dotpinzone, QType::DS, dsset);
bool verified = false;
for (const auto : dsset) {
if (*ds.dr.d_content == dsrc) {
verified = true;
break;
}
}
if (verified) {
cout<<"server pubkey matches a DS"< The pseudo DNSKEY record MUST NOT be present in the zone.
>
> Also, instead of showing openssl commands, explain to the reader the
> process of the resolver.
I agree.
We chose the openssl format because it is unambiguous, but it is not
the best form for an explanation. We chose to keep the draft short by
not reiterating the protocol for the separate implementation paths (a
client uploading a DS, a client uploading a DNSKEY, and a resolver
doing the pin validation) for -00. We felt it would be better to have
the protocol fully hashed out before describing it in multiple
contexts.
> What does it fetch, when does it fetch it, what
> information is extracted and used.
I hope the sample above helps. We'll work on improving the draft for
this.
> Your draft also state:
>
> The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in
> [RFC7344]) records. These records MAY be present in the zone.
>
> I think that should be a MUST, not a MAY. Or else a rogue parent
> inserting DS records to MITM the TLS cannot be detected.
Your previous email also mentioned something like this, and I've been
thinking about it. What I get stuck on is 'if the parent does that,
they might as well also change the NS records and the DS records
related to actual DNSKEYs'.
> > > Conveying that you can do DoT using DS can only really be done by
> > > overloading the record type.
> >
> > Which field do you mean by 'the record type'? We chose the algorithm
> > field for it.
>
> I meant key tag. We have seen issues in the past with both resolver
> behaviour with unknown algorithms and registries limiting their drop
> down menus for DS components to only valid algorithms.
For resolvers: in January 2019, when the idea for this draft started to
form based on Manu Bretelle's DSPKI draft, we did some experiments to
find out how big this problem is. At the time, Unbound, PowerDNS
Recursor and BIND were fine with unknown algorithms not having real
DNSKEYs. Google Public DNS, Knot Resolver (and by extension, 1.1.1.1)
did choke on it. Both have been fixed since.
For registries: yes, many of them limit their drop down menus (or EPP
interfaces, or CDS/CDNSKEY interfaces) to valid algorithms. We trust
that an IANA registration for algorithm 'TBD' will eventually fix that.
> I thought using keytag 0, which cannot happen normally, would allow
> you to leave algorithm and other values more real.
If the registry interface is 'DNSKEY', there is no way to set the key
tag to zero. We wrote the draft as it is now, precisely to be
compatible with registries that expect (C)DNSKEY instead of DS.
> > > If we don't want to hard fail, then I think we should just
> > > drop this
Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Sun, 2020-05-24 at 13:43 -0400, Paul Wouters wrote: > 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. The draft says 'The pseudo DNSKEY record MUST NOT be present in the zone.' What can we add to the text to make it clear that no query is sent to the zone's name servers -until- their TLS key has been verified? > 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. In our proposal, the DS record conveys 'do DoT' and also authenticates the TLS channel. > Conveying that you can do DoT using DS can only really be done by > overloading the record type. Which field do you mean by 'the record type'? We chose the algorithm field for it. > If we don't want to hard fail, then I think we should just > drop this draft and use opportunistic. This draft, that signals and key-pins, with hard failure, would not prevent an opportunistic draft/RFC to also exist. (But, repeating myself from another reply, with my 'resolver developer' hat on, and on behalf of our users with their 'resolver operator' hats on, opportunistic is a software complexity and user-experienced-latency burden that I'm not a big fan of.) > If we want to offer hard fail, > then some draft is still useful. Why not this draft then? :) > I would use the keytag record set to 0 to mean this DS record is not > a real DNSKEY but "something else". This will require changes in registry software all over the world, or some hack . I'm not saying that's prohibitive, but our draft is the way it is because this is one of the many hurdles we wanted to avoid. > Whether you need anything else > is debatable. You could use the digest field to stuff in a public key. We stuff the hash of the public key (with the rest of the DNSKEY format prefixed) in the DS. > 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. Which is exactly what the draft provides. > In your draft, you cannot connect with privacy until you obtain the > base64 encoded TLS key embedded in the DNSKEY RRset. No, that's simply not the case. Apparently the draft is unclear - can you help us make the language better so this confusion does not occur? > > 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. I also do not believe that, but it's nice that we can do without the extra roundtrip anyway! 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Tue, 2020-05-19 at 11:46 -0400, Paul Wouters wrote: > On Tue, 19 May 2020, Peter van Dijk wrote: > > > The draft is managed on GitHub in .md format at > > https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin > > We first added the KEY RRTYPE in the 1990's to allow generic public > keys in DNS. Then the DNS (and CA) people got upset at the KEY record > being used for something else than securing DNS. So KEY was obsoleted > for DNSKEY that signified it is for DNSSEC only. And we are forever stuck with a '3' that I keep forgetting the meaning of :) > This draft now tries to shoehorn a TLS key into the DNSKEY record. > > A much cleaner solution would be to use a proper TLSA record. If you > want to signal securely within DNSSEC that encrypted DNS is available, > use a DNSKEY flag on the existing DNSKEYs to signal that (similar to > the DELEGATION_ONLY flag). You only need 1 bit and TLSA records - which > are port specific - can be used to signify presence of DoT or DoH. Or > if you want to support both on port 443 for middleware circumvention, > you can use _dot and _doh prefixed (eg _443._dot.nohats.ca IN TLSA As I remarked in my reply to Jeremy, I spent quite some time thinking about how to do the signalling with actual TLSA records, but I never ended up with a satisfactory solution. https://github.com/PowerDNS/parent-signals-dot/blob/master/README.md has some terse notes on fitting TLSA to this problem. Perhaps we should add similar notes to the draft in a not-for-publication section? For your specific proposal, how would I see the DOT_TLSA flag on the nohats.ca DNSKEY without first querying for that DNSKEY over a plain text connection to your name servers? 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. > The TLSA records can also be of different types, so you can pin the TLSA > record to a pubkey, certificate or specific CA. This would allow the DoH > or DoT maintainer to change/update their keys witout needing to update > or have access to the DNSSEC signer to update the DNS. In our 'emulation' (or perhaps re-syntaxing) of TLSA, we explicitly chose to only map TLSA Certificate Usage 3, because all other forms require that you are confident about the name of the remote end you are connecting to. As delegation NS records are not signed, those usages would be susceptible to attack if the TLSA records are not somehow tied to both the delegated domain name -and- the names of its name servers. '_443._dot.nohats.ca' (ignoring, for a moment, that it lives in the child zone and thus is not available when the resolver needs it for safely connecting to the nohats.ca name servers) does not tie itself to the names of the name servers, and thus cannot support anything other than TLSA Certificate Usage 3. Of course, I've had to read between the lines of your proposal a bit, as it was specified very tersely. If you, or somebody else, comes up with a fully fleshed out proposal based on TLSA, I would be very interested in reading it! 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Tue, 2020-05-19 at 10:56 +0100, Jeremy Harris wrote: > On 19/05/2020 10:24, Peter van Dijk wrote: > > Name: draft-vandijk-dprive-ds-dot-signal-and-pin > > Revision: 00 > > It's almost-but-not-quite DANE, and a TLSA record. Why (not)? I've thought about many ways to use actual TLSA records, and have read previous drafts and proposals in emails to this group. None of it seemed satisfactory to me. There are some terse and biased notes in https://github.com/PowerDNS/parent-signals-dot/blob/master/README.md - happy to elaborate on anything I wrote in there. (There's a side-issue with TLSA, depending on how you use it: in many TLSA 'modes', you are expected to confidently know the name of the thing you are connecting to. NS records in delegations are not signed, so if you misdesign something based on TLSA, you could end up connecting to ns.attacker.example with its entirely valid key/certificate.) 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] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
On Tue, 2020-05-19 at 11:51 +0200, Mikael Abrahamsson wrote:
> On Tue, 19 May 2020, Peter van Dijk wrote:
>
> > please find below all details about our proposal for enabling DoT from
> > resolver to authoritative.
>
> Thanks, interesting approach.
Thanks!
> Some thoughts...
>
> "If the DoT connection is unsuccessful or the public key
> supplied the server does not match one of the DS digests, the
> resolver MUST NOT fall back to unencrypted Do53."
>
> Can we somehow make this behavior configurable by means of a flag (or
> something) by the domain holder? To say if fallback is ok or not?
Yes, we have imagined a few ways to make that possible:
* careful use of DNSKEY flags
* a special DNSKEY value ('empty')
But we've had trouble figuring out a decent use case for allowing the
fallback.
With my 'resolver developer' hat on, I don't want probing/fallback code
in the hot resolution path, it adds complexity and hurts performance.
> Also, when I want to roll keys, can I specify multiple keys during this
> key roll period?
Yes, specifying multiple keys (i.e. placing multiple DS records) is allowed.
This is necessary because separate NSes might have different keys, and
conveniently this enables key rolling as well.
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
[dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Hello DNS privacy people, please find below all details about our proposal for enabling DoT from resolver to authoritative. This work is based on Manu Bretelle's presentation in Prague over a year ago, after which we spent a lot of time figuring out how to squeeze the DoT signal and key pin into the constraints of DNSKEY/DS records. We have some running code (linked in the draft) to show feasibility of the approach. The draft is managed on GitHub in .md format at https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin Looking forward to your comments, Peter, Manu & Robin Forwarded Message From: internet-dra...@ietf.org To: Peter van Dijk , Emmanuel Bretelle < chan...@fb.com>, Robin Geuze Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds- dot-signal-and-pin-00.txt Date: Tue, 19 May 2020 02:18:23 -0700 A new version of I-D, draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt has been successfully submitted by Peter van Dijk and posted to the IETF repository. Name: draft-vandijk-dprive-ds-dot-signal-and-pin Revision: 00 Title: Signalling Authoritative DoT support in DS records, with key pinning Document date: 2020-05-19 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt Status: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ Htmlized: https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-vandijk-dprive-ds-dot-signal-and-pin Abstract: This document specifies a way to signal the usage of DoT, and the pinned keys for that DoT usage, in authoritative servers. This signal lives on the parent side of delegations, in DS records. To ensure easy deployment, the signal is defined in terms of (C)DNSKEY. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for adoption: draft-bortzmeyer-dprive-rfc7626-bis-02.txt
On 27 Mar 2019, at 15:29, Brian Haberman wrote: > All, > This is a call to judge consensus on adopting: > > Title : DNS Privacy Considerations > Authors : Stephane Bortzmeyer > Sara Dickinson > Filename: draft-bortzmeyer-dprive-rfc7626-bis-02.txt > > as a DPRIVE WG document. Please voice your opinion on the WG adopting > this document by April 17, 2019. While I have not recently read RFC7626, and thus cannot judge how much of an improvement this bis is, having read part of this document, I agree with its adoption. I do see that it will need some work before publication. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Some additional signalling ideas
On 31 Mar 2019, at 16:22, Ilari Liusvaara wrote: DS is signed, and has algorithm field. Supposedly unknown algorithms are ignored, but there are buggy nameservers out there that break if all DS entries have unknown algorithm. And turns out abusing DS records also runs into issues with "cloud" DNS provoders. Do you know of any name servers out there that have a problem with it, other than Knot Resolver, 1.1.1.1 and 8.8.8.8? (who all should be fixed soonish) Adding another RRtype with needed magic properties would take Standards Action (as expert review requires RRtype not to be magic) and then updating parent nameservers to be able to deal with the RRtype (since it can not be generically handled). And trying to add extra fields to NS or DS is sure to cause horrible borkage. I think adding fields might be even more painful than adding a new type. Neither seem feasible options to me. Adding records at child side of cut has its own issues, namely that retroactive authentication can be annoying to implement, and it is more difficult to make the thing work without full DNSSEC chain (glue records, if parent supports that?). manu’s proposal explicitly targeted unsigned delegations, which I also think is an important use case. Glue records are never signed. 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] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
Hello, On 24 Mar 2019, at 18:45, manu tman wrote: This proposal actually reminds me a lot of idea I had that actually used DS records instead of new record type. AFAIK: - DNSsec ignores any such record (unknown algorithm) -> No interference with DNSsec. - CDS does not ignore such records. -> Automated synchnonization. - Lives on parent side of delegation. -> No post-hoc authentication. I heard this idea twice today, and it sounds interesting. From what I gather from Paul Wouters is that not all registrars may accept unknown algorithms as well as they would validate that the DS is valid by checking the presence of the DNSKEY in the child. This would seem to be the biggest hurdle. Signalling & anchoring DoT in DS was suggested to me by a friend some time ago as well. Yesterday, Pieter Lexis and I ran some experiments with this (before catching up to this thread!). Looking up weird-ds1.7bits.nl/TXT (weird algorithm) and weird-ds2.7bits.nl/TXT (weird digest type) should return insecure on your favourite validator. Google DNS (8.8.8.8) and Knot Resolver disagree. A Knot resolver has informally confirmed this as a bug. I’m sure we can convince Google of the same, so on the validator side, deployment seems feasible. Registrars/registries are a different problem - but that problem is not entirely dissimilar from the slow rate of adoption of new algorithms (ECDSA, Ed25519) that we’ve seen in some registries. It is also a problem that can, over time, be fixed. Personally I like the DS signalling idea a lot, but I do see the ‘cloud provider’ problem angle. 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
[dns-privacy] FOSDEM 2018 DNS devroom CfP
Hello DNS-enthusiasts and other developers, (the text below has also been posted at https://blog.powerdns.com/2017/11/20/fosdem-2018-dns-devroom-cfp/ and if anything changes, we'll update that post, so please check there if you have questions. Also, our apologies if you receive multiple copies of this CfP via different mailing lists.) After two successful BoF sessions at FOSDEM 2016 and 2017, FOSDEM 2018 will see a real DNS devroom! We hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding, or system administrators responsible for DNS infrastructure. We have been allotted half a day on Sunday 4 February 2018. We expect to schedule 30 minutes per talk, including questions, but this is open to discussion. If you have something you'd like to share with your fellow developers, please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM18. Examples of topics are measuring, monitoring, DNS libraries, and anecdotes on how you've (ab)used the DNS. The deadline for submission is December 8th. If you have a FOSDEM pentabarf account from a previous year, please use that account. Reach out to dns-devroom-mana...@fosdem.org if you run into any trouble. We are also looking for volunteers to help with cameras etc. Please drop us an email at dns-devroom-mana...@fosdem.org if you're interested in helping out. See you there! Cheers, Peter van Dijk, Shane Kerr, Pieter Lexis ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
