I’m glad to see this proposal, I find it personally preferable to the dnscurve-esque proposal with the base32-encoded NS names. In both cases, however, the examples assume that the nameservers are in bailiwick for the zone. This is not going to be true for any side using a cloud authoritative DNS provider, which is fine.
However, I also think it should be possible for cloud providers to offer DoT transparently, without customers needing to opt-in. (I’m open to rebuttals to that, but I don’t see any obvious drawbacks.) I’d like to see the ability to scale either of these proposals to cloud services, but I’m not quite sure how that would work. Consider the following delegation from the gTLD servers: example.com 3600 IN NS ns1.clouddnsprovider.com example.com 3600 IN NS ns2.clouddnsprovider.com Now, under the clouddnsprovider.com zone, the provider can create the necessary DSPKI or base32-encoded NS records for “clouddnsprovider.com” in the gTLDs. But under my reading of this proposal, that means DOT would only be used to look up names under “clouddnsprovider.com”, not “example.com”. But, the recursive _knows_ that ns1.clouddnsprovider.com is capable of doing DoT (assuming TLS negotiation was successful). Therefore, I think it should be able to use DoT to lookup names under example.com (or indeed, under any domain which has the same (ns name, address) tuple. I’d like to see this use case explicitly addressed in the text of the draft. Unfortunately, I’ll only be able to attend the first 10-15 minutes of DPRIVE before I have to leave for the airport, but I’d be happy to discuss this further in a side-meeting or ad-hoc. Thanks, Jon -- Jon Reed <[email protected]> Senior Performance Engineer Nameservers Service Performance From: manu tman <[email protected]> Date: Monday, March 11, 2019 at 12:52 PM To: "[email protected]" <[email protected]> Subject: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt During earlier discussion (post virtual meeting), there were a mixture of feeling as to where SPKI may be published, here is one proposal bump (through the rush of time) to publish it in the parent zone. Manu ——— A new version of I-D, draft-bretelle-dprive-dot-for-insecure-delegations-01.txt has been successfully submitted by Emmanuel Bretelle and posted to the IETF repository. Name: draft-bretelle-dprive-dot-for-insecure-delegations Revision: 01 Title: DNS-over-TLS for insecure delegations Document date: 2019-03-11 Group: Individual Submission Pages: 7 URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01.txt&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI&s=PTJU2WP56vNJ3OnZN8sxwflDDPzJTP2kbMe7zyinhT8&e= Status: https://urldefense.proofpoint..com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI&s=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI&s=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4&e=> Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI&s=gwClruoLv-Mu6Sxl37_kCyxOu6Vx5QBV1ppRA0_m5aw&e= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI&s=MyhcqxSfzLUA2UhuM22MPzog5cLn6OxC_EwQPH7Qe6Y&e= Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=aRgHK985qD76PXQaxDKSjA&m=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI&s=aXUkzkp72a1sBvkWpiF9xYstuFWDnXcVoJTRRtLN2tA&e= Abstract: This document describes an alternative mechanism to DANE ([RFC6698]) in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative server by not making DNSSEC a hard requirement, making DoT server authentication available for insecure delegations. 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=_xTHEvws93UZ7jl9jhO7Pg&m=Wd41zdFrBer8CbvE8IcsmswCHFw9t1jpnqp_Gc9ifmk&s=4W3NnQBFNBwU4tl-AbrJMTVqBokRnB5hZQQuQZNlinQ&e=>. The IETF Secretariat
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
