[ietf-provreg] Re:

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

On 2008-12-30 00:32, liste@publisher.de wrote:
>
> Hello,
>
> my name is Ulrich and I am working for .SE (the Swedish registry). Among
> other other things I am responsible for the .SE EPP server.
>
> During the implementation of our EPP server (and client) I found the
> <secDNS:rem/>  definition to be incomplete. I have no idea if this has
> already been discussed on the list? I haven't been able to find it in
> the archives. Please feel free to point me to any old discussion if
> applicable.
>
> For<secDNS:rem/>  only keyTag can be specified. But DNSSec explicitly
> defines the keyTag to be *not* unique for a zone. Only algorithm an
> dkeyTag together are unique. Besides that it is possible to specify
> several DS records for the same key but with diffrent digestTypes.=20
>
> Currently due to the low depolyment of DNSSec and due to the fact that
> only one algorithm is required in DNSSec this is not really a problem,
> but it could become one in the future.
>
> Here at .SE we currently publish two DS records for every key, one with
> digest type SHA-1 and one with digest type SHA-256. (Try dnssec.se)
>
> My proposal would be to add two optional tags to the<secDNS:rem/>  tag
>
>       <secDNS:alg/>
>       <secDNS:digestType/>
>
> Which would be fully backward compatible, but still allow to be more
> precis if needed.
>
> Kind regards
>
> Ulrich

Hi Ulrich,

I discovered this issue back in 2005. I got two answers, one from Scott 
Hollenbeck, vaguely referring me to some not further specified discussions on 
the dnsop list and one from Ólafur Guðmundsson. Unfortunately, I couldn't find 
the latter e-mail in the list archive, so I cannot point to this e-mail, but 
have to quote it from my personal archive:

- - - 8< - - -
 > * Using the 16 Bit key tag of the key to identify the DS/DNSKEY that
 >   should be removed from the domain is a bit risky having the probability
 >   in mind that more than one key has exactly this tag. DNSSEC never relies
 >   on the uniqueness of this tag.

First question: Who gets harmed
Answer: Registrant.

As the number of DS at any delegation is supposed to be small (<=5) the 
probability of collision is low, as the keys pointed to by DS are supposed to be 
strong it is real stupid to have keys that collide. In short this is going to be 
infrequent if DS set is a replace operation then this is a non issue.
A smart registry is perfectly within the protocol bounds by refusing the a DS 
that conflicts in the key_tag + alg, (or if the digest for two keys of the same 
alg is the same).
- - - 8< - - -

Regards,

Klaus