Re: [ietf-provreg] Anyone working on 4310-bis?

[Howard Eland <heland@afilias.info>]

Sorry, I did not answer this yesterday.

On Nov 2, 2009, at 9:46 AM, James Gould wrote:

> Howard,
>
> So if we “go to the well once” without backward compatibility  
> support, the
> schema would do the following:
>
> 1. Remove support for the chg

So I did some sleuthing to try and figure out the logic of how and why  
chg was implemented in the first place, and I _think_ I've got it.  I  
believe that chg was used when attributes should always have a value  
of some sort.  I went  back through 4931, then back to 3731, looking  
specifically at AuthInfo.  While all of these say that a <domain:null>  
can be used in :chg, I note that in the XML there's a comment about  
adding the null value, which makes me think that at some point a null  
was not allowed, thus requiring a chg command.  I also note that in  
5733, the chg requires at least one child element to update contacts.

I think an argument can be made that :chg is an atomic method for  
replacing all DS records with new ones, without ever having a (albeit  
temporary) state in the DNS where a DS doesn't exist.  This however is  
solving the wrong problem: while there's always a DS in the zone, what  
we ultimately care about is client validation.  The most extreme case  
I can come up with is an emergency KSK rollover.  Should this occur,  
one can easily argue that removing the old DS records (rendering the  
zone invalid for a neg TTL potentially) and immediately (even within  
the same update) adding is as good as an replace (where, while the  
replace is processing, a validator could query and receive the bad DS  
record for a full TTL).

 From this perspective, the only reason to continue to support :chg  
would be because others are currently using it.
Because of this, I support the deprecation of :chg for DS records.

> 2. Remove support for rem with just keyTag

Not sure how this is different from (4), but I'm OK with this.

I've read Andrew's argument about keeping only the keyTag as part of  
the rem, but I'm concerned about making the text and XML correct with  
supporting only a keyTag IFF it removes one DS record, ELSE returns an  
error that specifies the problem, and possibly suggests adding all  
other parameters.

I do think we'll see quite a few registrants that send in the same  
keyTag w/ different digest types.  I am seeing a _lot_ of interest for  
this, from both test registrants as well as registrars, and it'll be  
more prevalent with the uptake of SHA-256.

> 3. Support for the combination of add and rem

Yes, provided the text clearly states that only one outcome can  
occur.  This can mean doing all adds first, or all removes first.  Of  
course, all adds can occur in any order, as can all removes.  Allowing  
policy to dictate how this works would be mean that registrars would  
have to support both.

> 4. Specify all of the DS information (keyTag, alg, digestType, and  
> digest)
> on an add and rem.

Yes - this needs to happen to ensure only a single DS is affected.

>
> As far as supporting a keyData interface and dsData interface to the  
> clients
> , I believe that client-side software (SDK’s and utilities) should be
> available for the client to generate the DS instead of pushing it to  
> the
> server-side.  With the dsData interface, the client has maximum  
> flexibility,
> the load is distributed to the client-side, and the registries can  
> provide
> one consistent interface.  It would be good to hear from the  
> Registrars
> related to supporting two different models across the DNSSEC  
> registries.

While registrar input is certainly important, I think it's really up  
to the registries that are authoritative for the DS record.  While I  
may not use this out of the gate, it's certainly an interesting idea,  
and it seems like something others said they would like to see.

-Howard


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se