Subject: repeating my mic comment on auth denial

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Mar 2005 14:12:30 -0500

Since the minutes of the meeting won't be out for a while, I thought 
I would repeat my comments at the mic regarding the authenticated 
denial issue.  (Fresh from a reading of the nsec3 draft, with the 
prospect of reading the bert proposal ahead of me.)

My comment is:

Before the WG commits serious resources to choosing one "new" 
approach to authenticated denial there is a need to hold a number of 
operations oriented workshops.  "Serious resources" means WG last 
calls, anything put before the IESG, etc.  Operations-oriented means 
software tools in our hands, and some semblance of reality in the 
test environment and scenario.

Why:

The NSEC3 document reminds me greatly of RFC 2065, a 
security-oriented document (salts, hashes, iterations, oh my) with 
unclear impacts on operations.  The first workshops based on RFC 2065 
- starting in Knivsta, SE, May, 1999 - represented about 5 years of 
protocol development.   It was still a few more years until the 
operator "friendly" DS RR was defined.

Even with 5 years of security expertise as input RFC 2065 was so 
operations unfriendly that it took years to fix the problem and years 
more to generate a new definition.  I don't want to repeat that 
experience.

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

Achieving total enlightenment has taught me that ignorance is bliss.

--
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: Ben Laurie <[email-masked]>
Date: Thu, 17 Mar 2005 11:41:30 +0000

Edward Lewis wrote:
> Since the minutes of the meeting won't be out for a while, I thought I 
> would repeat my comments at the mic regarding the authenticated denial 
> issue.  (Fresh from a reading of the nsec3 draft, with the prospect of 
> reading the bert proposal ahead of me.)
> 
> My comment is:
> 
> Before the WG commits serious resources to choosing one "new" approach 
> to authenticated denial there is a need to hold a number of operations 
> oriented workshops.  "Serious resources" means WG last calls, anything 
> put before the IESG, etc.  Operations-oriented means software tools in 
> our hands, and some semblance of reality in the test environment and 
> scenario.
> 
> Why:
> 
> The NSEC3 document reminds me greatly of RFC 2065, a security-oriented 
> document (salts, hashes, iterations, oh my) with unclear impacts on 
> operations.  The first workshops based on RFC 2065 - starting in 
> Knivsta, SE, May, 1999 - represented about 5 years of protocol 
> development.   It was still a few more years until the operator 
> "friendly" DS RR was defined.
> 
> more to generate a new definition.  I don't want to repeat that experience.

Don't worry, we are committed to producing the tools required to test NSEC3.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Mar 2005 12:23:03 +0000

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    >> Even with 5 years of security expertise as input RFC 2065 was
    >> so operations unfriendly that it took years to fix the problem
    >> and years more to generate a new definition.  I don't want to
    >> repeat that experience.

    Ben> Don't worry, we are committed to producing the tools required
    Ben> to test NSEC3.

Who's "we"? Producing tools and what have you to test NSEC3 is all
very well. But if they're coming from the people who write the NSEC3
draft, that test suite could be unsatisfactory. Please note I'm not
questioning the integrity of those writing the NSEC3 drafts. I am
saying that if the test suite comes from the same source as NSEC3, the
tests could be relying on knowledge that's in the heads of the authors
but not written in the spec; or the tests have too narrow a focus;
etc, etc.

That said, Ed's point is well-made. Once the NSEC3 draft is done,
there should be a period of experimental deployment with workshops and
interoperability events so that the draft can be tweaked if
operational experience suggests that's needed.