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

[Klaus Malorny <Klaus.Malorny@knipp.de>]

On 2009-10-27 21:56, Howard Eland wrote:
> The issue I brought up to Andrew involves the transform commands.  These
> only require the key tag to perform tasks such as remove, but, as
> mentioned in 4034, the key tag by itself may not be unique. We are
> seeing much interest in multiple DS records that have the same key tag
> with different digest types from registrants. If multiple DS records are
> added to the registry with the same key tag, and a subsequent transform
> command is sent with only the key tag, as specified in 4310, the result
> is left to interpretation.
>
> Possible solutions for this are:
> 1) Force the specification of <key tag, alg ID, digest type> for all
> transform commands (this requires the protocol change to 4310, and is
> where I'm headed).
> 2) Proceed to transform all DS records with this key tag in the same
> manner (but here too are dragons, as a change or update could result in
> either duplicate DS records, or would force the registry to remove the
> dups, causing a discrepancy between the registrar and the registry).
> 3) Do not allow multiple DS records with the same key tag (forcing key
> tags to be unique on the domain object - this seems like a non-starter
> to me).
> 4) Do not allow multiple DS records (also a non-starter).
>
> Thoughts?
>
> -Howard
>

Hi all,

interestingly, I pointed out the problem of RFC 4310 regarding multiple DNSKEY 
records having the same key tag about four years ago. This was not seen as a 
problem at that time, I was told that the user should just generate a new key 
pair to avoid the tag clash. Nobody (including myself) saw the problem of the 
need for multiple DS with different digest types for the very same DNSKEY 
record. Never mind.

I think RFC 4310 is still usable despite the drawbacks, and its use is probably 
better than reinventing the wheel. If the registrar chooses the <chg> option in 
the <element>, he can simply submit the desired DS records, even if there are 
multiple entries with the same key tag. For our implementation within the 
puntCAT registry, some basic testing is done, however: No two entries may exist 
with the same key tag and digest type. Also, algorithms must indicate the same 
key type (RSA vs. DSA). But if the registrars have problems with it, we might 
relax even this test. For the <add> element, a similar test is done on the 
resulting set of DS records. The <rem> element simply deletes all entries having 
the specified key tag(s), whether there are multiple entries per key tag or not. 
This may make the element useless, but this is IMHO the only choice.

Besides the problem above, I also dislike the following in RFC 4310:

- the <update> element is asymmetric to the <update> element in the base
   protocol and other extensions in so far that a <chg> element exists and
   that the <add> and <rem> elements are mutually exclusive.
- the submission of the key data is somewhat questionable. The only use
   is to verify the given DS data, which we do in our implementation.

Regards,

Klaus






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