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

[Ilari Liusvaara <[e-mail]>]

On Sun, Mar 24, 2019 at 06:45:31PM +0100, manu tman wrote:
> Thanks Ilari,
> 
> 
> > 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.

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

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

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

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

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