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

From: manu tman <[email-masked]>
Date: Mon, 11 Mar 2019 09:52:15 -0700

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=

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.

The IETF Secretariat

---

From: "Reed, Jon" <[email-masked]>
Date: Sat, 23 Mar 2019 00:58:46 +0000

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-masked]>
Senior Performance Engineer
Nameservers Service Performance

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

IETF repository.

Revision: 01

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:

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

---

From: manu tman <[email-masked]>
Date: Sat, 23 Mar 2019 21:43:11 +0100

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.

> 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
>
>
>
>
>
> --
>
> *From: *manu tman <[email-masked]>
> *Date: *Monday, March 11, 2019 at 12:52 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[dns-privacy] New Version Notification for
> 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:
> 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
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 24 Mar 2019 16:07:11 +0200

On Sat, Mar 23, 2019 at 12:58:46AM +0000, Reed, Jon wrote:
> 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.
> 
> 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.

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.

The problem that idea ran into was actually the same: If DNS is
outsourced to some external provoder (which is actually very
common), then key rotations need two parties to coordinate, which
is a nasty problem.

And then there is issue that not all nameservers for zone might have
DoT support, and in that case, one would have to discover which ones
do. And NS records might not be signed, so one can not rely on those.

The unreliability of NS pretty much means that unless all nameservers
support DoT, one has to duplicate nameservers into signed records. And
that might be multiple repetitions, which are not compressable, since
DS is not magic that way (even if it is magic due to where it lives).
Also, writing the nameserver name into DS record is not exactly
pleasant (as the field is hex-encoded).

One hack upon hack would be to have second key type be indirect
reference, which would then be looked up using new RRtype at the
target name. This would allow "cloud" case to work without annoying
coordination problems.

-Ilari

---

From: manu tman <[email-masked]>
Date: Sun, 24 Mar 2019 18:45:31 +0100

Thanks Ilari,

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

> common), then key rotations need two parties to coordinate, which

If CDS works, then it should be fine right?

> do. And NS records might not be signed, so one can not rely on those.

yeah, this would be a problem, even more if using multiple providers. On
the other hand, the NS selection heuristic should probably prefer a DoT
nameserver over one that does not support it when possible.

> pleasant (as the field is hex-encoded).

Yeah, NS is very much all or nothing and does not allow for ramping up
nameservers individually.

> target name. This would allow "cloud" case to work without annoying

I am not sure I am fully grasping this fully. Mind sharing a  bit more?

Thanks

Manu

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 24 Mar 2019 20:12:12 +0200

> This would seem to be the biggest hurdle.

Well, a new RRtype definitely would not work with unmodified
nameservers, since it has magic properties (it is on parent side of
zone cut without being glue).

> If CDS works, then it should be fine right?

Well, unless there are multiple provoders used at once, which
happens sometimes.

Or self-hosted DNS with cloud secondary.

> nameserver over one that does not support it when possible.

DNS is not exactly delay-tolerant, so one wants to minimize timeouts
and probing (unless said probing can be parallelized).

> I am not sure I am fully grasping this fully. Mind sharing a  bit more?

Something of style:

example.org. IN DS 0 137 2 <direct sha256 SPKI#1>
example.org. IN DS 0 137 42 <ns1.cloud1.example>
example.org. IN DS 0 137 42 <ns3.cloud2.example>
ns1.cloud1.example. IN IDK 2 <direct sha256 SPKI#2>
ns3.cloud2.example. IN IDK 2 <direct sha256 SPKI#3>
ns3.cloud2.example. IN IDK 2 <direct sha256 SPKI#4>

This gives four keys, presumably first is for self-hosted, the second
is for first cloud provoder, and last two are for second cloud provoder
that is rolling over its keys.

-Ilari

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 28 Mar 2019 08:21:49 +0100

Hello,

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Mar 2019 14:55:56 +0000

> >>   -> 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.finch  <[email-masked]>  http://dotat.at/
Great Orme Head to the Mull of Galloway: Variable 3 or 4, becoming southwest 4
or 5. Smooth or slight. Fair. Good.