[dns-operations] any registries require DNSKEY not DS?

[Warren Kumari]

On Thu, Jan 23, 2020 at 3:39 PM Florian Weimer <fw at deneb.enyo.de> wrote:
>
> * Warren Kumari:
>
> > On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:
> >>
> >> On Wed, Jan 22, 2020 at 10:13:40PM +0000, Tony Finch wrote:
> >>
> >> > Are there any registries that configure secure delegations from
DNSKEY
> >> > records (and do their own conversion to DS records) rather than
accepting
> >> > DS records from the registrant?
> >>
> >> In answer to the converse question, at least some registries appear to
> >> allow (or have allowed in the past) DS RRs with unverified content:
> >
> >
> > This actually seems OK to me -- nonsensical, but OK.
>
> It makes attacks on the underlying hash function for the DS record
> easier.  Constructing colliding prefixes is much harder if the prefix
> itself contains the hash over something else (because you also have to
> construct that something).

That's fair - but that's more of a (good) argument for the parent
calculating the DS from the DNSKEY than not allowing children to put in
things like unregistered algorithm/ hash types.  We’ve had lots of
deployment issues with things like restrictive registrar web interfaces
that don’t allow users to enter valid DS records because they haven’t been
updated yet; there is a trade off between protecting users from themselves,
and agility...

W





-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200123/eca6075a/attachment.html>