headers
Andrew Sullivan | 27 Oct 2009 20:47

Anyone working on 4310-bis?

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
ajs <at> shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request <at> cafax.se
Permalink | Reply | 49 comments |
headers
Patrick Mevzek | 27 Oct 2009 21:16

Re: Anyone working on 4310-bis?

Hello Andrew,

Andrew Sullivan <ajs <at> shinkuro.com> 2009-10-27 21:05
> 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. 

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 ietf-provreg-request <at> cafax.se
Permalink | Reply | 48 comments |
headers
Patrik Fältström | 27 Oct 2009 21:31
Picon
Favicon

Re: Anyone working on 4310-bis?


On 27 okt 2009, at 21.16, Patrick Mevzek wrote:

> Andrew Sullivan <ajs <at> shinkuro.com> 2009-10-27 21:05
>> 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.
>
> 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.

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

    Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request <at> cafax.se
Permalink | Reply | 46 comments |
headers
Andrew Sullivan | 27 Oct 2009 21:56

Re: Anyone working on 4310-bis?

On Tue, Oct 27, 2009 at 09:16:49PM +0100, Patrick Mevzek wrote:

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

-- 
Andrew Sullivan
ajs <at> shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request <at> cafax.se
Permalink | Reply | 0 comments |
headers
Howard Eland | 27 Oct 2009 21:56

Re: Anyone working on 4310-bis?

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

On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote:

>
> On 27 okt 2009, at 21.16, Patrick Mevzek wrote:
(Continue reading)

Permalink | Reply | 39 comments |
headers
Andrew Sullivan | 27 Oct 2009 22:02

Re: Anyone working on 4310-bis?

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

--

-- 
Andrew Sullivan
ajs <at> shinkuro.com
(Continue reading)

Permalink | Reply | 5 comments |
headers
Patrik Fältström | 27 Oct 2009 22:23
Picon
Favicon

Re: Anyone working on 4310-bis?

On 27 okt 2009, at 22.02, Andrew Sullivan wrote:

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

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? ;-)
(Continue reading)

Permalink | Reply | 4 comments |
headers
James Gould | 27 Oct 2009 22:31
Picon
Favicon

Re: Anyone working on 4310-bis?

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">
(Continue reading)

Permalink | Reply | 37 comments |
headers
Andrew Sullivan | 27 Oct 2009 22:25

Re: Anyone working on 4310-bis?

On Tue, Oct 27, 2009 at 10:23:12PM +0100, Patrik Fältström wrote:
> Aaaarrgghhhh!

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

A

--

-- 
Andrew Sullivan
ajs <at> shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request <at> cafax.se
Permalink | Reply | 0 comments |
headers
Edward Lewis | 27 Oct 2009 23:29
Favicon

Re: Anyone working on 4310-bis?

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.

>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? ;-)

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.

>Only possible path forward is to always:
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane