Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

["Reed, Jon" <[e-mail]>]

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 <[e-mail]>
Senior Performance Engineer
Nameservers Service Performance



From: manu tman <[e-mail]>
Date: Monday, March 11, 2019 at 12:52 PM
To: "[e-mail]" <[e-mail]>
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