Subject: [ietf-provreg] rfc4310bis 03 AD Feedback

From: James Gould <[email-masked]>
Date: Thu, 28 Jan 2010 09:59:11 -0500

All,

One of the items for the AD review of rfc4310bis is below.  I want to bring
this up to the list for feedback, since this is text from the original RFC.

>>       An OPTIONAL <secDNS:maxSigLife> element that indicates a child's
>>       preference for the number of seconds after signature generation
>>       when the parent's signature on the DS information provided by the
>>       child will expire.  A client SHOULD specify the same <secDNS:
>>       maxSigLife> value for all <secDNS:dsData> elements associated with
>>       a domain.  If the <secDNS:maxSigLife> is not present, or if
>>       multiple <secDNS:maxSigLife> values are requested, the default
>>       signature expiration policy of the server operator (as determined
>>       using an out-of-band mechanism) applies.
> 
> I am slightly surprised that the latter is not an error condition.
> But if this what people have implemented, then Ok.

So the question is around specifying different secDNS:maxSigLife values for
the secDNS:dsData (DS Data Interface) or secDNS:keyData (Key Data
Interface).  The RFC recommends (SHOULD) that the client use the same
secDNS:maxSigLife value, but does not mandate it.  The question is whether
the server signature expiration policy should apply when the client does
specify multiple values for a domain and the server accepts it.  It makes
more sense to me that the server should return an error if passing a
different secDNS:maxSigLife will result in the default being applied by the
server.  If an error is returned, I would propose returning 2306, since it
would be up to the server policy to have a single signature expiration
across all DS or keys of a domain.  If it¹s not up to server policy, then
the draft should use MUST instead of SHOULD for the client and the server
should return an error like 2305 ³Object association prohibits operation² or
2004 ³Parameter value range error².  I don¹t believe either 2305 or 2004
match the error exactly, but I guess I would lean towards 2004.  Any
opinions on which error code to use?

Please reply to the list or to me privately related to your preference on
this feedback.  

Thanks,

-- 

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: [email-masked]
Date: Thu, 28 Jan 2010 16:00:52 +0000

>   using an out-of-band mechanism) applies

Please forgive my ignorance, as I wasn't around when 4310 was written.

What's the rationale for giving the child _any_ say in the DS record 
signature lifetimes as presented in the parent zone?

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 28 Jan 2010 11:42:49 -0500

> signature lifetimes as presented in the parent zone?

The idea is that the child might want to have some maximum above which
it doesn't go, so that the child can roll keys in a predictable way.
This unfortunately ignores the effects of the RR TTL on the whole
issue, and IMO is a foot-gun loaded for bear, because it makes it
trivially easy to set the RRSIG short enough that an RRSIG expires
while in cache.  Without a knob to control TTLs, I don't know why
you'd allow this to be adjusted.

A

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

---

From: James Gould <[email-masked]>
Date: Fri, 29 Jan 2010 10:15:13 -0500

Is there anyone out there supporting or planning on supporting the client
specified maxSigLife.  In looking into this in more detail if this attribute
were supported, doesn¹t it make more sense for it to be an attribute outside
the dsData or keyData, since it applies to the domain¹s RRSIG and not to an
individual DS?  This means that it¹s an attribute of the domain and not of
the DS.  Since we¹re not worried about backward compatibility any longer
with the change in the URI we¹re open to remove or move this element.  Any
thoughts to this?  

-- 

JG 

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

From: <[email-masked]>
Date: Thu, 28 Jan 2010 11:00:52 -0500
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback

kind regards, 

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 31 Jan 2010 03:59:29 -0500

> specified maxSigLife.  In looking into this in more detail if this attribute

Afilias supports it now, IIRC.

A

---

From: James Gould <[email-masked]>
Date: Sun, 31 Jan 2010 10:23:13 -0500

Michael & Howard,

Do either you have thoughts related to the maxSigLife attribute in RFC 4310?

> But if this what people have implemented, then Ok.

I agree that at a minimum the server should return an error instead of
applying the server default when multiple maxSigLife values are requested.
To address this I have the following options.  I would like to hear from
anyone using the maxSigLife attribute or planning on using the maxSigLife
attribute.

1. Keep the maxSigLife as an element of secDNS:dsData or secDNS:keyData.
Update the text to require the server to return an  2305 ³Object association
prohibits operation² or 2004 ³Parameter value range error² error when
multiple maxSigLife values are requested.  I¹m leaning towards the 2004
error.  I would also recommend that we change ³A client SHOULD specify the
same <secDNS:maxSigLife> value² to ³A client MUST specify the same
<secDNS:maxSigLife> value², since I don¹t know the use case where the value
could be different per DS.
2. Move the maxSigLife element out of the secDNS:dsData and secDNS:keyData,
so that it can be set as a single value for a domain.  The maxSigLife
applies to the RRSIG, so it doesn¹t make much sense to set it at the DS
level.  This would mean that maxSigLife would be an optional element
directly under secDNS:create, secDNS:update, and secDNS:infData.  This
breaks backward compatibility, but backward compatibility is already broken
by changing the URI.
3. Remove the maxSigLife element all together.  This doesn¹t sound like much
of an option if there are servers using it.   This breaks backward
compatibility, but backward compatibility is already broken by changing the
URI. 
4. Update the text to allow for different maxSigLife values without the
server applying the default.  If we allow for multiple maxSigLife values I
don¹t believe it is correct for the server to return a successful response
and then pretty much ignore the requested values.

If there are any other options for this or if there are preferences to the
options I proposed above, please respond to the list or to me privately.

Thanks,

-- 

JG 

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

From: Andrew Sullivan <[email-masked]>
Date: Sun, 31 Jan 2010 03:59:29 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback

A