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

[manu tman <[e-mail]>]

Hi Jon,



> 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.
>

I think there may be business decisions as to whether or not this will
should transparent to the user vs being able to easily opt them in. I would
wish for this to be transparent and automatically enable wherever possible,
but people in that side of the business (which I am not in) may have
different opinions, I would like to hear those.



>
> 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.
>

As is, the SPKI would be used to validate the servers ns{1,2}.
cloudprovider.com but there is definitely a disconnect when it is out of
bailiwick. We should be able to articulate something for that case though.
I am at the IETF till EOW. Let’s meet and brainstorm how that could work
out for this scenario.

Manu

>
>
> 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
>
>