Subject: [ietf-provreg] Re:

From: [email-masked]
Date: Tue, 30 Dec 2008 00:32:25 +0100 (MET)

Subject: <secDNS:rem/> definition
From: Ulrich Wisser <[email-masked]>
To: EPP Provreg <[email-masked]>
Date: Tue, 30 Dec 2008 00:31:01 +0100

--=-6xtJpR9glNucMLPpIB5J
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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
=20

--=-6xtJpR9glNucMLPpIB5J
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

--=-6xtJpR9glNucMLPpIB5J--

---

From: Klaus Malorny <[email-masked]>
Date: Tue, 30 Dec 2008 01:18:40 +0100

On 2008-12-30 00:32, [email-masked] wrote:
> For<secDNS:rem/>  only keyTag can be specified. But DNSSec explicitly
> My proposal would be to add two optional tags to the<secDNS:rem/>  tag
>
>       <secDNS:alg/>
>       <secDNS:digestType/>
>

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