Subject: RE: New version of draft-ietf-dnsext-dnssec-online-signing

From: "Scott Rose" <[email-masked]>
Date: Tue, 10 Jan 2006 09:40:44 -0500

I read the draft, and I don't have any issues with it going forward.

I did notice that this draft is also relaxing the guidelines about the
bitmap field of dynamicly generated NSEC RRs.  Section 3, fourth paragraph
says:

  "The generated NSEC record's type bitmap SHOULD have the RRSIG and
   NSEC bits set and SHOULD NOT have any other bits set.  This relaxes
   the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
   names that did not exist before the zone was signed."

in RFC 4034 and 4035, the SHOULD(s) are MUST(s).  Perhaps another sentence
stating that restriction is relaxed as well.

Scott
****************************************
Scott Rose
Adv. Network Tech. Div., NIST
+1 301-975-8439

https://www-x.antd.nist.gov/dnssec/
****************************************

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Olaf M. Kolkman
> Sent: Tuesday, January 10, 2006 3:59 AM
> To: Namedroppers
> Subject: New version of draft-ietf-dnsext-dnssec-online-signing
>
>
>
> draft-ietf-dnsext-dnssec-online-signing-01 has just been published.
>
> The main difference between this and the previous document is that an
> applicability statement has been added. With this applicability
> statement it is thought that the underlying issue brought up during
> last call have been addressed.
>
> Please respond before the end of this week (Friday 17:00 CET) if you
> have serious issues with this modification.
>
> If there are no further comments the document will be published as is.
>
> See http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-online-
> signing/ for details.
>
> --Olaf
>    Co-Chair
>
> -----------------------------------------------------------
> Olaf M. Kolkman
> NLnet Labs
> http://www.nlnetlabs.nl/
>
>
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Jan 2006 15:52:13 -0500

> draft-ietf-dnsext-dnssec-online-signing-01 has just been published.

[. . .]

> If there are no further comments the document will be published as is.

I have reviewed this document, and have no objections to it
proceeding.

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Jan 2006 16:28:00 -0500

Reading from:

http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-online-signing/draft-ietf-dnsext-dnssec-online-signing-01.txt

Section 1 has this...

What is an 'instantiated name' ?  Do you mean a name that has at 
least one resource record set?

Section 2 has this...

    Due to
    these concerns, this technique should only be used when the need to
    avoid exposure of zone contents is overwhelming.

I want to be more precise than "overwhelming."  I suggest this as a 
replacement.  (I will add that could probably undergo further 
grammatical review.)

The technique is should only be used when damage caused by the 
systemic exposure of the zone contents is greater than the damage 
that could be incurred by either an abuse of the signing process 
(denial of service) resulting the zone becoming unavailable or a loss 
of confidentiality of the signing key resulting in forged responses.

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

Inactionable unintelligence is bliss.

---

From: David Blacka <[email-masked]>
Date: Tue, 10 Jan 2006 18:03:27 -0500

On Jan 10, 2006, at 4:28 PM, Edward Lewis wrote:
> (denial of service) resulting the zone becoming unavailable or a  
> loss of confidentiality of the signing key resulting in forged  
> responses.

I, too, don't particularly like that sentence in the document, but I  
think it would be easier to just delete it.  I would also delete the  
last sentence in section 2.  As much as I think the caveats in  
section 2 and section 6 are all true, I actually think the current  
version of the document is actually too defensive.

In general, I'm a little uncomfortable publishing drafts that say,  
essentially, "don't use me!".  Instead, they should list all of the  
known concerns and let the reader make the decision if the costs and  
risks are acceptable.

So, to let the online-signing document actually stand up for itself,  
I suggest that, in section 2:

   Due to these concerns, this technique should only be used when the  
need to avoid
   exposure of zone contents is overwhelming.

should be deleted. In the sentence

   This technique is likely to expose slightly more information	about  
the zone
   than this technique (e.g. the number of instantiated names), but  
it will still
   likely be preferable to this technique.

I suggesting changing it to "..., but it may be preferable to this  
technique." And the last sentence

  Anyone contemplating use of this technique is strongly encouraged  
to look for
  such future innovations.	

should be deleted as well.			

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Jan 2006 22:24:35 -0500

At 18:03 -0500 1/10/06, David Blacka wrote:

>essentially,
>"don't use me!".  Instead, they should list all of the known concerns and let
>the reader make the decision if the costs and risks are acceptable.

Good point.

...

>And the last sentence
>
>  Anyone contemplating use of this technique is strongly encouraged to look for
>  such future innovations.
>

I didn't like the "future innovations" as well.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 19 Jan 2006 20:13:22 -0500 (EST)

Edward Lewis writes:

> replacement.
...

And David Blacka writes:

> ...  As much as I think the caveats in

First, thank you VERY, VERY much for suggesting specific wording
changes.

I'm willing to include the changes, but I'm a bit concerned that
addressing two of these (the "future innovations" and the
defensiveness) will lead to a document that doesn't address Ted
Hardie's DISCUSS.

His comments seem to have disappeared from the ballot, but you can
still see them in the draftracker's document history:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13129&rfc_flag=0

I've CC'ed Ted on this note.  Hopefully he'll come over to visit us
here on namedroppers and argue the case himself.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Jan 2006 20:41:59 -0500

>defensiveness) will lead to a document that doesn't address Ted

Looks to me that Ted withdrew his discuss...so I don't know what to add.

...

2006-01-06
Version :01
[hardie] [Ballot Position Update] Position for Ted Hardie has been 
changed to No Objection from Discuss by Ted Hardie

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Jan 2006 18:04:42 -0800

At 8:41 PM -0500 1/19/06, Edward Lewis wrote:
>[hardie] [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie

I changed my position to No Objection after Margaret and the chairs indicated
that an applicability statement would be added to the document.  That seemed
to handle the issue that had been raised during Last Call by Roy and others as
well as pushing the document as experimental would have.  My reading of
Olaf's note when he started this thread is that he thought the same. 

I think the original applicability statement was reasonable guidance, and that
Ed's original re-write:

>The technique is should only be used when damage caused by the systemic exposure of the zone contents is greater than the damage that could be incurred by either an abuse of the signing process (denial of service) resulting the zone becoming unavailable or a loss of confidentiality of the signing key resulting in forged responses.

was okay, though a little hard to parse.

I kind of grok the preference just to drop the whole thing, but I think we need to
retain some of the flavor of the language that says "hey, online signing
is a big hairy security deal, don't do it unless you need to".  Section 6 lays out what
the issues are, but an applicability statement says to the reader:  "Here's when you
need to tackle those issues, and in other circumstances you can do simpler things."
I absolutely agree that it's up to those deploying this to know when they need to,
but guidance on the point seems appropriate as well.

				regards,
					Ted Hardie

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 22 Jan 2006 22:12:23 -0500 (EST)

I submitted -02 on Friday -- it should appear tomorrow morning.  I
think it addresses all of the issues raised last week as well as the
ones Ted raised during IESG review.

Thanks to Ed and David for including suggested text with their
comments.

-- Sam