[DNSOP] Spinning out of scope on draft-...-delegation-trust...

[Edward Lewis <[e-mail]>]

Perhaps again I’ll be labelled as a potential troll for this.  Again, using an example for a non-specific comment...

On Apr 14, 2014, at 7:09, one person wrote:

> At 10-04-14 21:54, someone else:
> 
>> We already have too many parents that have I do not know how many
>> stupid rules for ...
> 
> While I agree with you some (TLD) parents are sometimes too pedantic,

It is not in scope for the WG to judge the requirements which various DNS registries (TLD and otherwise) have signed up to meet.  It would be far more constructive to accept actual, demonstrated needs than such for a tech-utopia.  One of the things I learned when comparing DNSSEC operations to protocol engineering was that operators face a wide range of environments.  If the IETF is to produce protocols that are universally appealing, then the protocol has to pander - or be so good that it results in “simplifying” the number of different environments.  The IETF desires greater operator involvement, you don’t get that by complaining about the operators’ use cases.

Process-wise I’m surprised to see a new version come out before the end of the last call.  There was a draft a few years ago that I was following.  Each time I’d redline half a copy I’d learn that the one I was reading had been replaced by the next.  That wasn’t a last call time, so it was annoying.  But this time there is a last call and I would think the editors should wait for any stragglers.  (This time I did respond earlier.)

The rest of this I may have said before.  This draft (the CDS/CDNSKEY) describes an interchange from essential the key manager of the child zone and the provisioning system of the parent zone.  The communications medium is one direction, no feedback possible, but the client (in the sense that one end takes the initiative) can detect changes made by the server.

This is like (analogy time) one person who can speak to another and see the result, but there’s no other communication path. (Unrelated, this also applies to praying.)  Staying in-band only, the only way to make this work is to involve relative time (time-outs).

I do not to intend to say this is dead when I say: this cannot scale (unquantifed).  I mean that, in the sense we give up on scaling, we can define a protocol.

I think it is silly to burn two RR types to communicate the same thing.  You’re inviting debate on testing and handling the two being out of sync.

I don’t have a problem with leaving the records in as long as the parent is supposed to have the record represented in its zone - but only because I’m willing to sacrifice scaling.  This causes less state to be maintained (but is does create a greater load on a parent system that is polling).

I think that all use of the communications medium has to adhere to the basic rules of security.    Here that being ZSK signed - knowing that the validation engine does not inspect the SEP bit - but that when considering this is a client key manager to parent provisioning protocol (not DNS), the extra signature should be there.  (Come to think of it, the ZSK RRSIG is a redundant, but don’t expect cache-protecting validators to respect the SEP bit.)

Please take steps to simplify the protocol and discussion.  Giving up on scaling can make this a tool that some operators can use - and perhaps on a small scale within an organization.  It would be interesting to see is a general purpose DNS implementation will try this to manage a set of zones (as opposed to managing zones in isolation).

DNSSEC is clumsy.  It needs a solution here.