Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I managed to delete instead of sending my note on this topic earlier
today, and my brain is sufficiently soft that I couldn't just re-type
it out.  Nevertheless,

On Tue, Jul 18, 2017 at 03:19:44PM +0200, Willem Toorop wrote:
> I support trying to come up with a standards solution for alias names at
> the apex.  But....

I agree with this, and

> The dependency on online signing is a little more then just a technical
> issue.

also this.  

> Currently all DNS Resource Records support the "offline" domain-name
> holder signed zones mode of DNSSEC.  There is another provisioning
> oriented resource record: DNAME.  For DNAME, it is described how
> validators can verify that the followed referral matches. The same thing
> should be done for ANAME.

The problem is that DNAME has another feature that ANAME (and other
things like BNAME) can't: RFC 6672 gives the reasons why all
validators must also be able to cope with DNAME.  This was a fact (or
maybe accident) of history.  It is just not true of ANAME, and that
means that much of section 3 of the I-D is far too weak.  It needs to
say that, if you can't sign online, then you will break DNSSEC.

It is very strange for us to suggest this, but I think there are only
two options: either DNSSEC means we can never do any more aliasing, or
else we have to accept that some kinds of innovation in the DNS is
going to break DNSSEC sometimes, and allow zone operators to decide
whether they want to break validation (and therefore lose the
connections) or whether they want to serve everyone.

Alternatively, of course, we can follow the multiple-algorithm
approach that others have suggested.  This has the disadvantage of
bloating the DNSKEY RRset for anyone who wants to use these features,
of course, so it is also not free.

I'm also slightly concerned about this at the end of 3.3:

   The type bit map SHOULD only include address types which are known
   to exist at the <target>

Is the advice really to ask for both and then incorporate what is
known?  That seems maybe safer advice.

I also wonder whether the document would be easier to understand if it
were broken up into smaller chunks dealing separately with the
authorities, intermediates, and stubs.  It could be that nobody else
find these items too tangled in the current I-D, but if others do I
can propose text.

A

-- 
Andrew Sullivan
[e-mail]