Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
> >> 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. There's a problem with CDS and unknown algorithms. RFC 7344 section 4.1 third bullet requires the parent to verify that the delegation will not be broken by new DS RRset. This means the parent needs to check that it is able to validate every algorithm, otherwise it could open up a downgrade attack. Note that this validation is not just checking that the DS records have matching DNSKEY records; the parent must also validate that at least one matching key has signed the DNSKEY RRset (because that's what normal validators will need to be able to do). So unknown algorithm hacks will not work with CDS as things currently are. Tony. -- f.anthony.n.finchhttp://dotat.at/ Great Orme Head to the Mull of Galloway: Variable 3 or 4, becoming southwest 4 or 5. Smooth or slight. Fair. Good. ___ 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
I support adoption. Regards, Hugo Connery -- Head of IT, DTU Environment, http://www.env.dtu.dk From: dns-privacy [dns-privacy-boun...@ietf.org] on behalf of Brian Haberman [br...@innovationslab.net] Sent: Wednesday, 27 March 2019 15:29 To: dns-privacy@ietf.org Subject: [dns-privacy] Call for adoption: draft-bortzmeyer-dprive-rfc7626-bis-02.txt 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. This draft will be discussed during the DPRIVE session at IETF 104. Regards, Brian & Tim ___ 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-hzpa-dprive-xfr-over-tls-01.txt
> On Mar 11, 2019, at 7:07 PM, Sara Dickinson wrote: > > A new draft has been submitted outlining using DNS-over-TLS for zone > transfers. > Hi Sara, I wonder if you would be willing to include a reference to the ZONEMD work in this draft. Just as RFC 7858 says that TLS and DNSSEC are independent and solve different problems, I think it would be good to point out here that xfr-over-tls is not a substitution for being able to verify the integrity of zone data as published. DW smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [dns-privacy] Call for adoption: draft-bortzmeyer-dprive-rfc7626-bis-02.txt
> -Original Message- > From: dns-privacy On Behalf Of nusenu > Sent: Thursday, March 28, 2019 12:29 AM > To: dns-privacy@ietf.org > Subject: Re: [dns-privacy] Call for adoption: draft-bortzmeyer-dprive-rfc7626- > bis-02.txt > > > > Brian Haberman: > > 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. > > I support the adoption of this draft. +1 -Tiru > > > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
