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

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 15:47:48 -0400

Dear colleagues,

I have of late observed a couple possibly pointy corners in RFC 4310,
and Howard Eland just pointed out to me a pretty big operational
problem in it, so I am wondering whether anyone is working on updates
to it.  If not, Howard and I will prepare a -00 with some suggestions,
and solicit feedback.  If so, please let us know about it so that we
can offer our contribution.

Thanks and best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 27 Oct 2009 21:16:49 +0100

Hello Andrew,

Andrew Sullivan <[email-masked]> 2009-10-27 21:05
> to it. 

I'm not specifically working on it, but I would advise anyone dealing
with DNSSEC and EPP to have a look at what .CZ did and what .EU will
do soon, as they both created other extensions to handle DNSSEC with
EPP. Maybe other registries too. Sorry if you did that already.

I'm not judging pro or in favor of any other extension, 
but I believe that having a look at the currently deployed EPP
dealings with DNSSEC would be a good idea in light of future work on
4310.

Hope that helps.

-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/> <http://www.dotandco.net/>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 27 Oct 2009 21:31:10 +0100

> dealings with DNSSEC would be a good idea in light of future work on

We use epp and DNSSEC in .SE since a while back. What are the issues  
you think?

    Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 16:56:52 -0400

> EPP. Maybe other registries too. Sorry if you did that already.

I haven't done anything yet, happily :) I was figuring that the .CZ
and .EU (and .SE) experiences would have to inform the work.  See my
other message in this thread for a big issue, though.

A

---

From: Howard Eland <[email-masked]>
Date: Tue, 27 Oct 2009 15:56:18 -0500

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 17:02:27 -0400

On Tue, Oct 27, 2009 at 09:31:10PM +0100, Patrik Fältström wrote:
> We use epp and DNSSEC in .SE since a while back. What are the issues you 
> think?

Howard pointed out to me that the key tag is what is used to do
operations on a DS.  That's fine, until you're trying to roll
algorithms, because of this happy bit in RFC 4034:

   The key tag is the same for all DNSKEY algorithm types except
   algorithm 1 (please see Appendix B.1 for the definition of the key
   tag for algorithm 1).

One operational model for moving from SHA-1 to SHA-256 is to add a new
key using both SHA-1 and SHA-256, and then remove the SHA-1 version
after some time.  Now, one might want to say, "Don't do that," but I
think the document either ought to say that or else specify a way to
identify DS records that does not rely on the key tag.  Also, of
course, if there turned out to be a major problem with one or the
other algorithms, one would want a way to yank one of the keys without
yanking the other.  I haven't completely thought through this,
however.  The only way I know how really to think through something is
to write the text (I'm dim), so I thought I'd ask whether someone is
working on text.  If so, I could figure out how to add to it, or else
I could just write something new.

A

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 27 Oct 2009 22:23:12 +0100

>   algorithm 1 (please see Appendix B.1 for the definition of the key

Correct, the key tag is the (only) index when you want to do  
operations. Hmm...have not thought about having multiple keys with  
same key tag.

Yeah, also just saw this in 4034:

> The key tag is used to help select DNSKEY resource records
> efficiently, but it does not uniquely identify a single DNSKEY
> resource record.  It is possible for two distinct DNSKEY RRs to have
> the same owner name, the same algorithm type, and the same key tag.
> An implementation that uses only the key tag to select a DNSKEY RR
> might select the wrong public key in some circumstances.  Please see
> Appendix B for further details.

Who the heck came up with this? ;-)

Changing this in epp will not be simple. There are tons of deployed  
things out there (i.e. if we change to {keytag, algorithm} instead of  
just {keytag}).

The text above from 4034 do though say:

> It is possible for two distinct DNSKEY RRs to have
> the same owner name, the same algorithm type, and the same key tag.

That is _not_ fun.

Only possible path forward is to always:

1. Remove all keys (in .SE we use keytag=0 to remove all keys)
2. Add the keys again

But there is a risk you have the zone with no keys then.

Aaaarrgghhhh!

    Patrik

---

From: James Gould <[email-masked]>
Date: Tue, 27 Oct 2009 17:31:12 -0400

I'm glad that this thread has come up, since I too was going to propose
something similar to option 1 but with making the specification change
backward compatible.  We are implementing to 4310 for .com, .net, and .edu
with no additional extensions.  We see the issue with use of just the
keyTag, since it is derived and is not unique.  There are use cases where
for the same key, which means the same keyTag, there could be multiple
digest types and algorithms.  My proposal is to add optional attributes
(alg, digestType, and digest) to the <secDNS:keyTag> element of <secDNS:rem>
and to add verbiage for the registries to match the DS record for the delete
based on all of the passed information.  If there is more than one matching
DS record for the input, than an error must be returned.  The following is
what I would propose for the XML schema change:

Original XML schema:

    <complexType name="remType">
        <sequence> 
            <element name="keyTag" type=" unsignedShort"
maxOccurs="unbounded"/>
        </sequence>
    </complexType> 

Updated XML schema:

    <complexType name="remKeyType">

        <simpleContent>

            <extension base="unsignedShort">

                <attribute name="alg" type="unsignedByte"/>

                <attribute name="digestType" type="unsignedByte"/>

                <attribute name="digest" type="hexBinary"/>

            </extension>

        </simpleContent>

    </complexType>

    <complexType name="remType">

        <sequence>

            <element name="keyTag" type="secDNS:remKeyType"
maxOccurs="unbounded"/>

        </sequence>

    </complexType>

An example of the resulting secDNS:rem for deleting two DS records with the
same keyTag value but with a different algorithm, digestType, and digest is
below:

      <secDNS:rem>
        <secDNS:keyTag alg="1" digestType="5"
digest="48EC35D5B3A34B45C399">12345</secDNS:keyTag>
        <secDNS:keyTag alg="2" digestType="3"
digest="38EC35D5B3A34B44C39B">12345</secDNS:keyTag>
      </secDNS:rem>

One additional proposed change is to clarify the use of the <secDNS:chg> to
state something like ³is used to replace all existing DS information with
new DS information².  The information associated with the specified keyTag¹s
is not the only information changed, since the interpretation is that the
<secDNS:dsData> elements provided with the <secDNS:chg> is a wholesale
replacement of the all of the existing dsData information.  Have any of the
registries interpreted the <secDNS:chg> in a different way?

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

> From: Howard Eland <[email-masked]>
> Date: Tue, 27 Oct 2009 15:56:18 -0500
> To: EPP Provreg <[email-masked]>
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 17:25:11 -0400

> Aaaarrgghhhh!

Yes.  Hence my interest in doing something about this.  :-)

A

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Oct 2009 18:29:34 -0400

At 22:23 +0100 10/27/09, Patrik Fältström wrote:

>Hmm...have not thought about having multiple keys with same key tag.

That's probably because dnssec-keygen won't 
return a key that has the same keytag as another 
one in it's view.

>Who the heck came up with this? ;-)

I'll blame Olafur.

>That is _not_ fun.

Neither is a lot of other stuff in DNS - like 
round robin, case preservation, etc.  It's not 
fun, but not an obstacle.

>1. Remove all keys (in .SE we use keytag=0 to remove all keys)

We could specify the DS record by the key hash in 
the DS.  This is about provisioning the DS after 
all.

If there's gonna be an update to 4310, it has to 
be out there soon.  We haven't gone live, but, we 
have already implemented RFC 4310 as is.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Howard Eland <[email-masked]>
Date: Tue, 27 Oct 2009 18:27:10 -0500

There's a lot of ways to skin this cat.  All of them that I can see  
involve an RFC update (even if it's just for clarification).  So, I  
seem to be hearing "yes, fix this, but hurry up about it".  If this is  
the case, then is there anything else that folks would like to see in  
4310-bis?
(who has the worm-can opener?)

Other comments below.

On Oct 27, 2009, at 4:31 PM, James Gould wrote:

> DS record for the input, than an error must be returned.

I'd rather not include the digest itself here, since the <keyTag,  
algID, digestType> tuple uniquely identify the DS record.

I'm not sure we have to maintain backwards compatibility, but,  
assuming we do, an error could be returned anytime multiple DS records  
are matched, as you suggest, or we could also affect the remove  
against all records that match those attributes sent in (in other  
words, the default is to match all for any given attribute).

>  The following is

[...]

> state something like “is used to replace all existing DS information  
> with
> new DS information”.  The information associated with the specified  
> keyTag’s

To make <secDNS:chg> the most versatile, I'd still like to have the  
ability to specify the other attributes.  That way, it can be used to  
change one or more DS records, as opposed to having to replicate all  
DS records to change one.  This would make syntax similar to  
<secDNS:rem>, and would still be backwards compatible: if you don't  
specify the keyTag or any other attributes, then they all change.

-Howard

>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
>>> =-
>>> =-=-=-

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 28 Oct 2009 09:36:18 +0900

> But there is a risk you have the zone with no keys then.

How surprising!

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 28 Oct 2009 00:25:08 +0100

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
> 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.
>
> 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).

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Oct 2009 06:11:56 +0100

On 27 okt 2009, at 22.31, James Gould wrote:

> My proposal is to add optional attributes

I like this, specifically with the keyword "optional". That way, it  
would be backward compatible with deployed implementations (on the  
client side), and roll out of the new mechanism is as smooth as  
possible.

    Patrik

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 28 Oct 2009 12:45:54 +0100

Here at .SE we implemented 4310. As pointed out earlier there is 
potential for further development. ;)

The first problem is the update tag as it doesn't allow add and rem in 
the same command. This definition could be changed (with backwards 
compatibility) from <choice> to <sequence>.

The bigger problem is the secDNS:rem tag. As pointed out additional 
information (alg, digestType) is needed. At .SE we use SHA-1 and SHA-256 
by default for all keys. Try "dig @a.ns.se dnssec.se DS" for example.

In the past months I have seen many registrars struggle with the rem tag 
because it works fundamentally different from the rest of EPP.

I would propose several solutions:

A. totally backward compatible
    Add optional attributes to the secDNS:keyTag tag. But this would 
mean that alg and digesttype are attributes to keytag which isn't really 
the case. Backward compatible but not a clean solution.

B. Not backward compatible
Revamp the whole rem tag and insert a new grouping like
<secDNS:rem>
   <secDNS:dsData>
     <secDNS:keytag/>
     <secDNS:alg/>
     <secDNS:digestType/>
   </secDNS:dsData>
   <secDNS:dsData>
     <secDNS:keytag/>
     <secDNS:alg/>
     <secDNS:digestType/>
   </secDNS:dsData>
<secDNS:rem>
This would make the whole thing work more like the rest of EPP.

And while we are at it I would like to propose another change:

The add command (as well as update) uses the secDNS:dsDataType. Which 
makes keytag, alg, digestType and digest mandatory. I know that .SE and 
other registries considered to become a "fat" registry and take in the 
public keys instead of the ds records. The DS records would be computed 
from the public keys according to registry policies.
This case is not covered by 4310.

Kind Regards

Ulrich

-- 
Ulrich Wisser
senior developer
.SE (The Internet Infrastructure Foundation)
PO Box 7399, SE-103 91 Stockholm, Sweden
Visits: Ringvägen 100 A
Switchboard: +46(0)8-452 35 00
Direct: +46(0)8-452 35 58
Mobile: +46(0)732-74 59 00
E-mail: [email-masked]
Website: http://www.iis.se

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Oct 2009 14:45:23 -0400

>Who the heck came up with this? ;-)

So Olafur and I are throwing rocks at each other over that question....

The idea of the keytag predates memory, the 
desire was to have someway to select one of the 
keys in an RRset.  (In DNS, there is no other 
selector "inside" an RRset.)

The reason that the keytag is non-unique is, 
well, the things it is trying to 
describe/compress in 16 bits are practically 
random.  You can't compress random data (think 
about it) without loss.  In this case, we lose 
uniqueness.

Perhaps you could hash the key instead ... hey, that's what the DS record does!

The mistake here is using the keytag and not the DS hash as the selector.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 29 Oct 2009 10:20:39 -0400

> This case is not covered by 4310.

While this is true, 4310 does provide an OPTIONAL <secDNS:keyData>
element.  Registry policy could require this.  Then you could get the
DS and the DNSKEY at the same time, and you could even check to be
sure the DS they're providing actually matches the DNSKEY they're
providing (and use that as a first-line test to make sure their plan
is sane.  If they can't generate the right DS, they are as likely to
have other problems as not, and it could well be that you want to stop
doing anything until it's sorted).  No?

I'm loathe to make the <secDNS:dsData> element OPTIONAL because it
would necessarily mean changing the XML schema, which would cause
changes to be strictly backwards incompatible.

A