Subject: Re: [dnsop] EPP-DNSSEC Document Updates

From: Samuel Weiler <[email-masked]>
Date: Mon, 24 Jan 2005 17:57:32 -0500 (EST)

First, -06 addresses all of the comments on the -03 version that I
sent in August, and is generally a much better document.  Thanks to
Scott for keeping up with the details.

I've split my comments on -06 into substantive (protocol) and
editorial.  First the substantive ones:

Section 2: "... the key data SHOULD have the Secure Entry
Point (SEP) bit set as described in RFC 3757."  I'd like to see
this be a 2119 MAY -- RFC3757 does not say SHOULD, and this document
does not document the need for the 2119 SHOULD.

Section 2.1.2: It's still not clear exactly how the <secDNS:infData>
element's sDate, eDate and vInterval should be used: in particular,
none of these seem to specify a desired RRSIG lifetime.  Perhaps sDate
and eDate are intended to do that, though it's likely that a DNSKEY
will be in use for far longer than the requested signing interval --
perhaps another field <maxRRSIGlifetime> is needed?  This way a client
could say: don't publish this DS until time X, use an RRSIG lifetime
no more than 3 days, resigning the DSset every day, and quit
publishing this DS after 30 days.

The security considerations, in the sixth paragraph, talks about some
revokation operations that makes no sense to me.

  First, it says "...a client should either remove the compromised
  key...".  'client' should be clarified -- do you mean "the child
  zone"?  And if a DNSKEY is removed without removing the
  corresponding DS, bad things happen.

  The next suggestion is to remove "the DNSSIG on the DS" (sic).  If
  the RRSIG(DS) is removed, that should throw an error UNLESS the NSEC
  is also updated to show no DS at the delegation.  In other words,
  this section needs serious work.  Miek and Olaf's DNSSEC operations
  draft may have useful words.

Earlier in the security considerations, in the third paragraph, is the
requirement: "...provisioning of public key information MUST only be
done after the identities of both parties have been confirmed...".  I
can understand a need to authorize (but not necessarily identify) the
client, but why is there any need to identify the server?  Would bad
thing could happen if you're talking to the wrong server?

And in the seventh paragraph of the security considerations, I don't
understand the need for a two-step process.  Why not just mark
clientHold?  Or is this section really trying to address the rapid
removal of the secure bits (the DS), but not the delegation?

Editorial comments:

This document uses the phrase "DNS security extensions" throughout.
I'd like to see "DNSSEC" appear somewhere, preferably in the Abstract.

Drop references to RFC3008, 3090, 3658, and 3757 -- all are obsoleted
by DNSSECbis.  Add a reference to the DNSSECbis Intro doc.

Section 1, last sentence: consider explicitly saying "DS resource
records" rather than just "DNS resource records".

Section 1.1 " Indentation and white space in examples is provided only
to illustrate element relationships and is not a REQUIRED feature of
this protocol."  This use of 2119 language seems odd to me.

Secion 2.1 uses the words "delegation zone" and "delegated zone".  I'm
more accustomed to seeing "parent" and "child".

-- Sam
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 25 Jan 2005 12:03:17 -0500

Thanks for reading the document again, Sam.  Whys and what-fors below.

-Scott-

> -----Original Message-----
> From: Samuel Weiler [mailto:[email-masked]] 
> Sent: Monday, January 24, 2005 5:58 PM
> To: [email-masked]
> Cc: Scott Hollenbeck
> Subject: Re: [dnsop] EPP-DNSSEC Document Updates
> 
> 

This text exists at the request of Ed Lewis.  Ed, what say you?  Would a MAY
be sufficient?

> publishing this DS after 30 days.

I don't have a strong feeling wither way about the maxRRSIGlifetime thought
above, but you have the intent correct.  s/eDate describe the client's
preference for the start and end dates of DS and RRSIG publication in the
parent zone; vInterval is the client's preference for the parent to
regenerate the RRSIG every "X" units.  What text would make that purpose
more clear to you?

>   corresponding DS, bad things happen.

Darn, I need to remove that "remove the compromised key".  That doesn't make
sense now that the RRSIG stuff is gone.

>   draft may have useful words.

Frankly I'd rather reword the suggestion to make it EPP-specific instead of
DNSSEC-specific.  Maybe a reference to Miek and Olaf's doc would be better.

> thing could happen if you're talking to the wrong server?

A needed urgent update might not get propagated.

> removal of the secure bits (the DS), but not the delegation?

Hmm, I suppose it could be either/or, depending on what the child really
wants.  Yes, that should be clarified.

> more accustomed to seeing "parent" and "child".

I'll take care of these.

-Scott-

.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Jan 2005 17:07:24 -0500

>publishing this DS after 30 days.

I'm going to take a stab at this from this comment.  (The section is 3.1.2.)

I'm cartooning this, refer to the draft for the full story:

Inside a dsData element:     req/opt       set by
        keytag                required      innate (client)
        alg                   required      innate (client)
        digestType            required      innate (client)
        digest                required      innate (client)
        sDate                 required      client wish, overruled by server
        eDate                 required      client wish, overruled by server
        vInterval             optional      client wish, overruled by server
        ttl                   optional      client wish, overruled by server
        keyData (4 subel'ts)  optional      innate, may be ignored by server

I suggest making the sDate and eDate optional.  The only indisputable 
elements are the keytag, alg, digestType and digest, there's no 
alternative to the client sending this.

All of the optional elements would then be subject to the statusData 
element in 3.2.1., answering Marco's comment.

The default value for sDate would be "now."  The default date for 
eDate would be the expiration time on record for the domain.  (For 
domains that don't expire, then the eDate is "forever.")

The expiration time on a domain is not the end of the domain's time, 
the domain may be later renewed - I think it's *arguably* reasonable 
to not change the eDate when this happens.  Hopefully at renewal the 
DS records are included in the invoice.  Like I say - arguable.

A registry may decide that it won't hold future records - like I 
would question the sensibility of storing keys that won't come of age 
until after the expiration time of the domain.

I think:
    sDate might be "now" <= sDate <= expiration time, default to now.
    eDate might be "now" <= sDate < eDate <= expiration time, default to expire

How does this relate to the RRSIG(DS) validity span?  It brackets it. 
I.e., no RRSIG(DS) should be temporally valid prior to sDate.  No 
RRSIG(DS) should be temporally valid after eDate.  But there can be 
an RRSIG(DS) that becomes temporally valid a day after sDate and 
becomes temporally invalid a day before eDate ("a day" for instance).

(Scott - this is my interpretation.  Correct me if I am wrong.)

And then for vInterval, well, I am a bit fuzzy on this one to tell 
the truth.  The client may want a new RRSIG(DS) done daily, but I 
can't quite fine a good reason why.  Hmmph.  I mean, if the client 
wants to remove the key in question, it can just remove it from the 
DNS at its end and the DS becomes a dangling reference, harmless for 
the most part, unless the reason for pulling the key was exposure. 
(In that case, the client ought to urgently get the DS pulled too.)

Speaking of urgent, the elements of statusData would now be

       sDate
       eDate
       vInterval
       ttl
       keyData
       urgent

And the allowed (by not always sensible) response would be 
"accepted", "ignored", and "missing."

But this doesn't really do [se]Date any good.  The dates are in the 
registry, not in the DNS.  Right?  Would then be in the WhoIs/IRIS? 
(Do we need to extend IRIS for DNSSEC data?  Note to check on that.)

Comments?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Jan 2005 16:41:37 -0500

>This text exists at the request of Ed Lewis.  Ed, what say you?  Would a MAY

The reason I think a SHOULD is correct -

(First the overarching plan)

The time will come when there will be a need to have automatic tools 
to measure and correct what's in the DNS.  Maybe not even in the next 
5 years, but eventually.  After working on the DNS protocol for years 
(I'm not talking about operations), my personal observation is that 
the protocol lacks management features.  The state of DNS operations 
is still rather healthy, but if we don't take steps to make it more 
manageable, someday I fear DNS will unravel.

'Course, the beauty of the DNS is that it is loosely coupled, 
enabling it to scale.

But, there are times in which more management is needed.

I am not talking about steps to make what's on port 53 more managed 
or more restricted.  I see the need for "health monitors" to be 
deployed to identify potential problems in the DNS tree.  Lord, umm, 
PVM knows, there are a lot of legal set ups in DNS that will cause 
nothing but pain and hardship.

(A concrete reason)

I want the SEP bit there to make diagnostic tools possible.  Not that 
I see a tool coming soon, but I want to make them possible today.  I 
believe that this is a prudent restriction in any delegation 
situation that is enabled via an EPP.

(The counter question)

Given that we are talking about operations, is there a reason why an 
EPP client would have the desire to provision a non-SEP key as a DS 
record?

(The big finish)

That's why I asked Scott to use a SHOULD.  The DS is intended to 
reference secure entry points or key signing keys.  The DS can 
reference zone signing keys, but then the DS will have to be changed 
so often we might as well go back to RFC 2065 mode.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 27 Jan 2005 17:18:04 -0500 (EST)

Another clarification:

The <secDNS:update> <secDNS:rem> takes a keyTag -- it should be
pointed out that multiple DS records might have the same keyTag
(perhaps they're for the same DNSKEY, just using a different digest
algorithm, or perhaps they're for different DNSKEYs with the same
keyTag) and that the <secDNS:rem> elements removes ALL matching DS
records.

-- Sam
.