Subject: [dnsop] Re: preview of op practices comments

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 17 Mar 2005 14:44:37 +0100

In addition to a bunch of nits  Samuel Weiler wrote:

>I'm not done with the last substantive section, but here's the current
>list, somewhat ordered.  I'll send the substantive ones to the list
>later.  I think the first item is critical.
>
>Section 4.2.1
>This section says that the pre-publish scheme doesn't work for KSK
>rollover (4.2.2.3 says the same thing.) -- I thought it did, so long
>as you were prepublishing DS records in the parent (hence publishing
>multiple DS records).  The current language seems to imply that no
>pre-publish scheme will work, and I'm extremely uncomfortable with
>that.
>
>  
>
We are CC-ing the dnsop list as this is a relevant content change that 
could do with WG review.

You are correct a pre-publish is possible.

We did two things. We reworded this paragraph to argue that it is not 
the most elegant way to roll the KSK and moved it behind the the 
sections on KSK and ZSK rollover

So the order is now.
     4.2   Key Rollovers  . . . . . . . . . . . . . . . . . . . . . .
       4.2.1   Zone-signing Key Rollovers . . . . . . . . . . . . . .
       4.2.2   Key-signing Key Rollovers  . . . . . . . . . . . . . .
       4.2.3   Difference Between ZSK and KSK Rollovers . . . . . . .

Below is the new text.

>Examples (sections 4.2.1, 4.2.2.1, 4.2.2.2, 4.2.3): Why do you show
>both keys, particularly the ZSK, signing the DNSKEY RRset?  I think
>the examples would be clearer if only the KSK signed the DNSKEY RRset.
>
>  
>

The currently most commonly available signer shows this behaviour.  We 
think following the behaviour of the signer is clearer.

>Section 3.5
>Is the table (and the cited paper) applicable to authentication?  (As
>compared to confidentiality.)  I'm not sure that it is, but I'm
>willing to go read the paper and ponder this some more.
>  
>
Its applicable to confidentiality and integrity. I do not think we have 
to change these recommendations in the light of the SHA1 vulnarability 
but I am not sure.  Guidance would be appreciated.

>Section 4.1.1, third bullet, re: making the TTL long enough to fetch
>all data for a verification.  Could we make an estimate?  5 sec.?  30
>sec?  60 sec.?
>
>  
>

We used to have this text, it got removed between version 01 and version 
02. Unless directed by the WG we keep this out.
             
    We have seen events where data needed for verification of an           
    authentication chain had expired from caches.           
    We suggest the TTL on DNSKEY and DSs to be between ten minutes    
       
    and one hour. We recommend zone administrators to chose TTLs           
    longer than half a minute.           

>-----------------
>
>Section 1.2
>         After one stopped publishing an RRSIG in a zone file it will
>         take a while before the RRSIG has actually been removed from
>         the DNS.
>Why?  (Yes, I know why, but the sentence seems to come out of the blue
>here.)
>
>  
>

Sentence now reads:

After one stopped publishing an RRSIG in a zone it
may take a while before the RRSIG has expired from
caches and has actually been  removed from the DNS.

>Section 2, third paragraph
>   Administrators of secured zones will have to keep in mind that data
>   published on an authoritative primary server will not be
>immediately
>   seen by verifying clients; it may take some time for the data to be
>   transfered to other secondary authoritative nameservers, during
>which
>   period clients may be fetching data from caching non-authoritative
>   servers.
>The part after the semicolon doesn't make sense to me as an
>explanation of the part before the semicolon -- if clients are talking
>to caches, what different does secondary update delay make?  This
>seems to be confusing two different things.
>
>  
>

Part after the semi colon rephrased as:

 it may take  some time for the data to be transfered to other secondary
authoritative nameservers and clients may be fetching data from caching 
non-authoritative servers.

>Section 3.1
>I suggest adding even more explicit text explaining that that the
>SEP flag is merely advisory, and that separation of these functions is
>not necessary.  I suggest something like the following (taken from
>draft-weiler-dnsext-dnssec-bis-updates-00 section 5):
>   Futhermore, note that the SEP bit setting has no effect on how a
>   DNSKEY may be used -- the validation process is specifically
>   prohibitted from using that bit by -records section 2.1.2.  It
>   possible to use a DNSKEY without the SEP bit set as the sole secure
>   entry point to the zone, yet use a DNSKEY with the SEP bit set to
>   sign all RRsets in the zone (other than the DNSKEY RRset).  It's
>also
>   possible to use a single DNSKEY, with or without the SEP bit set,
>to
>   sign the entire zone, including the DNSKEY RRset itself.
>  
>

I think that this addition is confusing. Personally I think that we 
should advocate the setting of the SEP bit as it helps troubleshooting.  
I think that leaving out the "protocol purity" text above will not 
introduce possible problems.

>Section 3.5
>Says " Also see Section 3.1.1."  My immediate question was "why?".
>The answer is "for a discussion of how keys serving different roles
>(ZSK v. KSK) may need different key strengths."  Consider saying that.
>
>  
>

We added your suggested text.

>Section 4.1.1, fourth bullet
>"RRSIGs in the zone server by the slave server" doesn't makse sense to
>me. 
>

That should have read "RRSIGs in the zone served by the slave server 
pass ..."

> I have a general note of "confusing" by the bullet -- I don't
>have specific changes, though. Later on in that bullet the phrases
>"slave zone" and "secondary zones" appear -- I don't think we want to
>use those terms. 
>
We reprhased that sentence:

 We also suggest that operators of nameservers that
 supply secondary services develop 'watch dogs' to spot
 upcoming signature expirations in zones they slave, and
  take appropriate action.

> There's also a sentence: "How quickly can I reach an
>administrator and load a valid zone?" -- should that be
>"master" or "primary" instead of "administrator"?
>  
>

Rephrased:

How quickly  can I reach an administrator of secondary servers to load a 
valid zone?

>Section 4.2.2.1
>      ... The minimum
>      duration of this pre-roll phase is the time it takes for the
>data
>      to propagate to the authoritative servers plus TTL value of the
>      key set.  This equates to two times the Maximum Zone TTL.
>This implies that it (may) take a TTL for data to propagate to the
>secondaries/slaves.  Stupid question: is that the right number?  Could
>it be constrained to something shorter?
>  
>
I hope its the right number (its what we tried to argue) and if it is it 
cannot be constrained (as we tried to argue)  :-)

>4.2.2.3
>First bullet: as before, why can't one pre-publish DS records?
>I find this statement disturbingly overbroad.  Also, pre-publish takes
>longer (an extra TTL?).  Also: s/just//
>  
>
Rephrased to:

Also the pre-publish scheme involves more parental work when used for 
KSK rollovers as explained in <xref target="keyroll"/>.

>4.2.3
>   ..., and where
>   removal of the keys by the child can be signaled by the parent. ...
>This is confusing me.
>
>  
>
Does this help:

Using an established trust relation, the  interaction can be performed 
in-band, and the removal of
the keys by the child can possibly be signaled by the parent.

>4.3
>   While an authentication chain to your compromised key exists, your
>   name-space is vulnerable to abuse by the malicious key holder (i.e.
>   the owner of the compromised key).
>"owner" implies to me "rightful owner", which means this doesn't make
>sense, but I'm not thinking of a good term.
>
>
>  
>
But isn;'t it clear from "the malicious key holder" to which the "i.e." 
refers?

These proposed modifications are made available through 
http://www.secret-wg.org/dnsop/
(an htmlwdiff at: 
http://www.secret-wg.org/dnsop/draft-ietf-dnsop-dnssec-operational-practices-03-04pre1.html)

If we receive no further comments in the next 10 odd days we'll post a 
new version and ask the
chairs to consider forwardingthe document to the IESG.

--Olaf and Miek

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

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 18 Mar 2005 09:54:24 +0000

On 17 Mar 2005, at 13:44, Olaf M. Kolkman wrote:

> But isn;'t it clear from "the malicious key holder" to which the 
> "i.e." refers?

No.

This language is too condensed for reliable interpretation by anyone who
hasn't participated in its writing.

Both "key holder" and "owner" suggest the rightful owner.

The vulnerability is (surely?) to abuse by anyone who has obtained
illegitimate possession of the key.

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 18 Mar 2005 10:10:42 +0000

On 18 Mar 2005, at 10:05, Olaf M. Kolkman wrote:

> So is this better:
> name-space is vulnerable to abuse by anyone who has obtained 
> illegitemate
> possession of the key.

I think so.

I see one remaining nit, regarding spelling of "illegitimate".

Best regards,

Niall O'Reilly

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 18 Mar 2005 11:05:09 +0100

So is this better:

While an authentication chain to your compromised key exists, your
name-space is vulnerable to abuse by anyone who has obtained illegitemate
possession of the key.

??

--Olaf
.