From galvin at elistx.com  Sun May  8 14:19:44 2005
From: galvin at elistx.com (James M Galvin)
Date: Sun, 08 May 2005 14:19:44 -0400
Subject: Spring Break is over
Message-ID: <A779D34C60B1D3A861D29EAE@[10.0.0.7]>

This is a reminder that we will be meeting this Wednesday at our usual 
time of 1900 UTC.

The agenda will not be know until at least Tuesday morning.  Please 
keep a watch for it.

Jim



From galvin at elistx.com  Tue May 10 15:19:25 2005
From: galvin at elistx.com (James M Galvin)
Date: Tue, 10 May 2005 15:19:25 -0400
Subject: meeting announcement: 11 May 2005
Message-ID: <E2158C0360138EB78B60D07C@[10.0.0.7]>

This meeting will be held at the usual time of:

    1200 Los Angeles, San Francisco
    1200 Phoenix
    1500 Washington
    1900 UTC
    2100 Netherlands
    2200 Israel
    0400 Tokyo (the next day)
    0500 Melbourne (the next day)

The usual teleconference logistics are as follows.  These do not change.
You will hear music until the moderator joins (that would be me).

    USA Toll Free Number: +1 888-221-7341
    USA Toll Number:      +1 973-935-2305

    Passcode: 599786
    Leader:   James Galvin
	      employed by ICANN if speaking to an operator

    Jabber:   dnssec-deployment at conference.jabber.org
	      This is a public room.

    If your phone does not have a mute capability you can use "*6" to
    mute and unmute your connection.

    DIAL OUT:
        1. ISC SIP Bridge - contact me for SIP identifiers


DRAFT AGENDA

 -- RIPE Meeting Report

    Jaap Akkerhuis led a panel similar to the one in Mar del Plata.
    Comments and suggestions from participants and those who were
    present are welcome.


 -- Google DNS issue

    Is the issue described in the NANOG thread mentioned below an
    incident that could have been mitigated with the use DNSSEC?

    From NANOG:

      Date:    Sun, 08 May 2005 02:18:19 +0000
      From:    "Fergie (Paul Ferguson)" <fergdawg at netzero.net>
      To:      nanog at merit.edu
      Subject: Google DNS problems?!?

      Does anyone else think that its a bit odd that if it were simply
      "DNS problems" that a redirect for www.google.com would end up at 
a
      location which provided this:

        http://img179.echo.cx/img179/7959/googlehacked7to.jpg

      [or]

         http://img241.echo.cx/img241/6208/googlemsn3lp.png

      Seems more than simple "DNS problems" to me.

      I hate being played like an idiot....


 -- Proposal for an interoperability meeting

    One of the activities this group could facilitate is
    interoperability testing.  The next RIPE meeting will be in October
    in Amsterdam.  It might be a good candidate for planning such an
    event.

    What do folks think?  Will enough folks be ready to participate?


 -- Regarding Issue 8 from the DNSSEC Deployment Roadmap:

      8. Computational and communication resources required

      Considers operational requirements for additional storage, CPU
      time and communication bandwidth and evaluates the affect these
      additional requirements may have on adoption and use.

    If available, Olafur and Jaap will present their material.

    * Olafur Gudmundsson

      Olafur Gudmundsson volunteered to create and maintain a list of
      metrics people should collect and use for reporting.  He noted
      that we needed metrics for both resolvers and servers.

    * Jaap Akkerhuis

      Jaap Akkerhuis noted that NL Netlabs had a simulation of CPU and
      storage requirements for DNSSEC.  Jaap agreed to get some material
      on the NL Netlabs activities for review.



From olaf at ripe.net  Wed May 11 04:05:48 2005
From: olaf at ripe.net (Olaf M. Kolkman)
Date: Wed, 11 May 2005 10:05:48 +0200
Subject: [dnssec-deployment] meeting announcement: 11 May 2005
In-Reply-To: <list-10321097@EXECDSL.COM>
References: <list-10321097@EXECDSL.COM>
Message-ID: <20050511100548.65f5f4ed.olaf@ripe.net>




I will (most probably) not be able to attend this evening.


-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org


From jaap at NLnetLabs.nl  Wed May 11 10:12:03 2005
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Wed, 11 May 2005 16:12:03 +0200
Subject: [dnssec-deployment] meeting announcement: 11 May 2005 
In-Reply-To: Your message of Tue, 10 May 2005 15:19:25 -0400.
             <list-10321097@EXECDSL.COM> 
Message-ID: <200505111412.j4BEC37N009336@bartok.nlnetlabs.nl>

     -- Regarding Issue 8 from the DNSSEC Deployment Roadmap:
    
    <...>
    
        * Jaap Akkerhuis
    
          Jaap Akkerhuis noted that NL Netlabs had a simulation of CPU and
          storage requirements for DNSSEC.  Jaap agreed to get some material
          on the NL Netlabs activities for review.


It turns out that there is less available then I thought. There is
a talk about adding DNSSEC support in nsd which also makes comments
about the resources in general dnssec needs (by the server) and has
some measurements comparing performance with and without dnssec,
but the with/without dnssec comparison is for nsd only  (See
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-dn-dnssec-nsd.pdf)

I had hoped to do some new measurements in cluding bind comparisons
in the 4 weeks mentioned above, but my day job got in the way.

And remember, as said before, Olaf has some decent numbers in his
introduction course.
    
	jaap


From bmanning at vacation.karoshi.com  Wed May 11 10:23:22 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 11 May 2005 14:23:22 +0000
Subject: [dnssec-deployment] meeting announcement: 11 May 2005
In-Reply-To: <list-10334076@EXECDSL.COM>
References: <list-10321097@EXECDSL.COM> <list-10334076@EXECDSL.COM>
Message-ID: <20050511142322.GE28625@vacation.karoshi.com.>

On Wed, May 11, 2005 at 04:12:03PM +0200, Jaap Akkerhuis wrote:
>      -- Regarding Issue 8 from the DNSSEC Deployment Roadmap:
>     
>     <...>
>     
>         * Jaap Akkerhuis
>     
>           Jaap Akkerhuis noted that NL Netlabs had a simulation of CPU and
>           storage requirements for DNSSEC.  Jaap agreed to get some material
>           on the NL Netlabs activities for review.
> 
> 
> It turns out that there is less available then I thought. There is
> a talk about adding DNSSEC support in nsd which also makes comments
> about the resources in general dnssec needs (by the server) and has
> some measurements comparing performance with and without dnssec,
> but the with/without dnssec comparison is for nsd only  (See
> http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-dn-dnssec-nsd.pdf)
> 
> I had hoped to do some new measurements in cluding bind comparisons
> in the 4 weeks mentioned above, but my day job got in the way.
> 
> And remember, as said before, Olaf has some decent numbers in his
> introduction course.
>     
> 	jaap
> 
> #############################################################

	there are some preliminary numbers from at least one other source,
	it should be presented at the upcoming NANOG... or at least 
	releasable then.  

--bill


From olaf at ripe.net  Wed May 11 10:28:19 2005
From: olaf at ripe.net (Olaf M. Kolkman)
Date: Wed, 11 May 2005 16:28:19 +0200
Subject: [dnssec-deployment] meeting announcement: 11 May 2005
In-Reply-To: <list-10334076@EXECDSL.COM>
References: <list-10321097@EXECDSL.COM>
	<list-10334076@EXECDSL.COM>
Message-ID: <20050511162819.5d5d5665.olaf@ripe.net>

> And remember, as said before, Olaf has some decent numbers in his
> introduction course.

The HOWTO to be presice... even more precise:
http://www.ripe.net/projects/disi/dnssec_howto/#id2432786    


-- olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org


From mankin at psg.com  Wed May 11 15:10:54 2005
From: mankin at psg.com (Allison Mankin)
Date: Wed, 11 May 2005 12:10:54 -0700
Subject: Jaap's intro slides from RIPE
Message-ID: <auto-000010339291@EXECDSL.COM>


I edited for the final participants.

------- Forwarded Message

Date:    Fri, 29 Apr 2005 21:41:22 +0200
From:    Jaap Akkerhuis <jaap at NLnetLabs.nl>
To:      Doug Barton <doug.barton at icann.org>, Ed Lewis <Ed.Lewis at neustar.biz>,
	 "Olaf M. Kolkman" <olaf at ripe.net>, Jakob Schlyter <jakob at rfc.se>,
	 Geoffrey Sisson <geoff at nominet.org.uk>, Peter Koch <pk at denic.de>,
	 Steve Crocker <steve at stevecrocker.com>,
	 Allison Mankin <mankin at psg.com>
Subject: Panel introduction slides

Hi,

I've just made some slides as introduction for the panel. My idea
is to start of with these and then everybody introduces themselves
with a couple of slides.  Please provide comments, opinions etc.

	jaap

- -----
The slides are basically text, so I have copied them in ascii below.
At shinkuro, I'll dump the ppt/pdf versions (original is keynoye).



No 1:

DNSSEC Deployment
Panel Discussion

RIPE 50, Stockholm May 2005
Moderator: Jaap Akkerhuis

No 2:
Previous meetings

Ripe 48, Amsterdam May 2004
NANOG 31, San Francisco May 2004
IETF 61, Washington
APRICOT, Kyoto February 2005
ICANN, Argentinia April 2005

No 3:
Myth Or Facts?

 - Signing zones is costly and and will not be done in absence of
  validating clients 
 - Configuring validating is costly in absence of a simple key maintenance
  scheme
 - Without application support end users do not care about DNSSEC 
 - The enumeration problem prohibits large scale DNSSEC deployment 
 - The enumeration problem will be solved in 6 months 
 - DNSSEC would have protected against the recent spoofing attacks

No 4:
The Crew

Olaf Kolkman
Peter Koch
Ed Lewis
Jakob Schlyter
Geoff Sisson

------- End of Forwarded Message



From mundy at tislabs.com  Wed May 11 15:48:08 2005
From: mundy at tislabs.com (Russ Mundy)
Date: Wed, 11 May 2005 15:48:08 -0400
Subject: DNSSEC Tools 0.1 Release Available
Message-ID: <p06210200bea8101d76d8@[10.88.70.38]>


Just so that we have the URL in the mail archive, our initial release of
dnssec tools as well as extensions for MTA & browser are publicly available
at:

http://www.dnssec-tools.org

We would like to have folks download the code, try it out and give us feedback.


Russ

p.s. dnssec-tools is a project on Source Forge.



From mundy at tislabs.com  Thu May 12 13:24:58 2005
From: mundy at tislabs.com (Russ Mundy)
Date: Thu, 12 May 2005 13:24:58 -0400
Subject: [CD-DNSSEC] [dnssec-deployment] DNSSEC Tools 0.1 Release
 Available
In-Reply-To: <050b01c55696$18c9f920$d35030c0@Marc4>
References: <050b01c55696$18c9f920$d35030c0@Marc4>
Message-ID: <p06210205bea941087348@[157.185.80.164]>

Marc,

That would be great.  This is still somewhat 'early code' (it is a version
0.1 release) so there will likely be some surprises but we really want to
have folks to give it a try and let us know what they think.

Russ

At 9:58 PM -0400 5/11/05, Marcus H. Sachs wrote:
>Russ, may I link to this via the SANS Internet Storm Center diary tomorrow?
>I presume this is ready for "general public" analysis and critique?
>
>Marc
>
>
>
>-----Original Message-----
>From: cd-dnssec-bounces+marcus.sachs=sri.com at csl.sri.com
>[mailto:cd-dnssec-bounces+marcus.sachs=sri.com at csl.sri.com] On Behalf Of
>Russ Mundy
>Sent: Wednesday, May 11, 2005 3:48 PM
>To: DNSSEC deployment
>Subject: [CD-DNSSEC] [dnssec-deployment] DNSSEC Tools 0.1 Release Available
>
>
>
>Just so that we have the URL in the mail archive, our initial release of
>dnssec tools as well as extensions for MTA & browser are publicly available
>at:
>
>http://www.dnssec-tools.org
>
>We would like to have folks download the code, try it out and give us
>feedback.
>
>
>Russ
>
>p.s. dnssec-tools is a project on Source Forge.
>
>
>#############################################################
>This message is sent to you because you are subscribed to
>  the mailing list <dnssec-deployment at shinkuro.com>.
>To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
>A public archive is available here:
><http://mail.shinkuro.com:8100/Lists/dnssec-deployment/>



From Ed.Lewis at neustar.biz  Thu May 12 13:30:20 2005
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Thu, 12 May 2005 13:30:20 -0400
Subject: What was that test DNS URL?
Message-ID: <a06200705bea9430f92c0@[10.31.32.227]>

Eh Bill?  www.rs.net?  Was that it?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.


From bmanning at vacation.karoshi.com  Thu May 12 13:40:57 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 12 May 2005 17:40:57 +0000
Subject: [dnssec-deployment] What was that test DNS URL?
In-Reply-To: <list-10353720@EXECDSL.COM>
References: <list-10353720@EXECDSL.COM>
Message-ID: <20050512174057.GE2593@vacation.karoshi.com.>

http://www.rs.net  is a valid/working URL.
it should describe a (sometimes) persistant testbed for 
doing goofy things to the DNS... like DNSSEC.

--bill


On Thu, May 12, 2005 at 01:30:20PM -0400, Edward Lewis wrote:
> Eh Bill?  www.rs.net?  Was that it?
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> If you knew what I was thinking, you'd understand what I was saying.
> 
> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/>


From galvin at elistx.com  Sun May 15 11:07:37 2005
From: galvin at elistx.com (James M Galvin)
Date: Sun, 15 May 2005 11:07:37 -0400
Subject: meeting cancelled: 18 May 2005
Message-ID: <EBF3E78F3D0B9A0DF490F38D@[10.0.0.7]>

The DNSSEC Deployment Working Group meeting for Wednesday, 18 May 2005, 
is cancelled.  Multiple people have conflicts that make it impractical.

We will meet again at the usual time on Wednesday, 25 May 2005.

Jim



From bmanning at vacation.karoshi.com  Tue May 17 12:41:05 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 17 May 2005 16:41:05 +0000
Subject: an academic study on resource usage
Message-ID: <20050517164105.GB3079@vacation.karoshi.com.>


this was hinted at last "call" in the jabber room

--bill



----- Forwarded message from Anja Feldmann <anja at net.in.tum.de> -----

Date: Tue, 17 May 2005 18:15:18 +0200
To: bmanning at vacation.karoshi.com

Hi Bill, 

I was running out of time trying to finish the paper draft and getting to
Seattle:-)

You can find a draft of the paper at:

    http://www.net.informatik.tu-muenchen.de/~anja/feldmann/papers/dnssec05.pdf

Any comments are more than welcome

    Anja

----- End forwarded message -----


From galvin at elistx.com  Sun May 22 14:17:09 2005
From: galvin at elistx.com (James M Galvin)
Date: Sun, 22 May 2005 14:17:09 -0400
Subject: meeting summary: 11 May 2005
Message-ID: <38C09BB881EA76302249822B@[10.0.0.4]>

DNSSEC Deployment Working Group
11 May 2005


PRESENT:
    Steve Crocker
    Jim Galvin

    Allison Mankin
    Amy Friedlander
    Bill Manning
    David Blacka
    Ed Lewis
    Geoff Sisson
    Jaap Akkerhuis
    Mark Kosters
    Matt Larson
    Olafur Gudmundsson
    Russ Mundy
    Sam Weiler
    Scott Rose
    Suresh Krishnaswamy
    Suzanne Woolf

REGRETS:
    Jakob Schlyter
    Olaf Kolkman
    Peter Koch


SUMMARY

 -- RIPE Meeting Report

    Jaap Akkerhuis led a panel similar to the one in Mar del Plata.
    Comments and suggestions from participants and those who were
    present are welcome.

Allison Mankin had heard the panel went well and was well received.  It
gave the impression of progress and commitment.  Jaap Akkerhuis noted
that the meeting is available on web cast.  However, the archive does
not fast forward so you have to watch it all.

    http://www.ripe.net/ripe/meetings/ripe-50/sessions-archive.html

A particularly good slide from Jaap was:

    Myth Or Facts?

     - Signing zones is costly and will not be done in absence of
       validating clients

     - Configuring validation is costly in the absence of a simple key
       maintenance scheme

     - Without application support end users do not care about DNSSEC

     - The enumeration problem prohibits large scale DNSSEC deployment

     - The enumeration problem will be solved in 6 months

     - DNSSEC would have protected against the recent spoofing attacks

Suzanne Woolf noted that more time was sorely needed.  There was a real
momentum beginning and it was stopped cold by a scheduling constraint.

Ed Lewis suggested we should focus more on the demand side rather than
getting registrars and registries on board.  They each have different
environments and we need to be careful to stay away from those
discussions.  They should each worry about their own economics and
getting applications to make requests and need DNSSEC will make that
happen.

Sam Weiler noted there was a lot of focus on the business case "myths"
and very little on the other "myths", e.g., the enumeration problem.  He
did not think the "6 month' myth was addressed very well at all.

Ed continued that we need to provide for testing for applications.  Each
registry has to make their own decision but there needs to be demand.
We are spinning away trying to be common.  We need some kind of testbed
environment.

Bill Manning noted the existence of:

    http://www.rs.net

It went moribund for a while.  it is still a little submerged but it is
slowly coming back to life.

Russ Mundy noted there was generally a good discussion but there was not
any great amount of rising enthusiasm as a result.

Sam added that he had trouble following it.  There did not seem to be
enough structure around the points being made.


Russ Mundy reported that his team has released a set of initial tools
that includes extensions for a web browser and MTA applications so that
they can make use of DNSSEC.  Please take a look at
<http://www.dnssec-tools.org>.  He is focused on trying to get
applications to use DNSSEC.


Regarding enumeration, Allison asked if the policies on keeping your
Whois information guarded, so you are not as worried about the degree to
which zones are accessible, ever came up.  Jaap said it was mentioned at
the end but by then they were out of time.  Regardless, it was his
impression that people have not thought about it too much.

Geoff Sisson commented that you can not effectively protect Whois; there
are too many BOTs and unsecured proxies that participate in harvesting.
You can only detect it by artifacts of BOT/proxy controllers, which is
increasingly harder and harder.


 -- Google DNS issue

    Is the issue described in the NANOG thread mentioned below an
    incident that could have been mitigated with the use DNSSEC?

    From NANOG:

      Date:    Sun, 08 May 2005 02:18:19 +0000
      From:    "Fergie (Paul Ferguson)" <fergdawg at netzero.net>
      To:      nanog at merit.edu
      Subject: Google DNS problems?!?

      Does anyone else think that its a bit odd that if it were simply
      "DNS problems" that a redirect for www.google.com would end up at 
a
      location which provided this:

        http://img179.echo.cx/img179/7959/googlehacked7to.jpg

      [or]

         http://img241.echo.cx/img241/6208/googlemsn3lp.png

      Seems more than simple "DNS problems" to me.

      I hate being played like an idiot....

Allison Mankin added for reference a quote from google about having been
offline found here:

    http://www.theregister.co.uk/2005/05/09/google_dns_glitch/

Is there a DNSSEC solution here?  If not, what is?

Jaap Akkerhuis explained that one thing that happens is people lookup
"google.com" and it is not there, there are still resolvers that will
starting adding domains on the end and resolve those, e.g.,
"google.com.net".  There was a company "com.net" that took advantage of
this.

Ed Lewis said that is a navigational problem, i.e., the query was
changed by the client asking the question.

Allison asked if there was a system level fix for this?  Ed responded
that you need to give the user enough information so they know they are
getting to the right place, not just that they are getting the right
information.  He has talked to some folks at JPRS about adding a display
of Whois information for the domain as well as signatures and other
security technology.  Because of IDN issues they think about these
issues more than many others.


Allison asked at what point do we say that DNS is not performing the
service it is supposed to be performing.  We could ask the "Internet
Storm Center" for information.  Ed suggested asking them to forward
information they otherwise can not divulge.

Allison took an action to make a call to collect some data on
incidents.  Although public reporting is flawed perhaps it will
encourage people to comment.  Ed suggested that to really know what is
going on you need an insider engineer's point of view.

Jaap Akkerhuis cautioned that if we are going to collect data we need to
consider how we could do this without going from incident to incident.



From Ed.Lewis at neustar.biz  Mon May 23 09:30:06 2005
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Mon, 23 May 2005 09:30:06 -0400
Subject: [dnssec-deployment] an academic study on resource usage
In-Reply-To: <list-10440250@EXECDSL.COM>
References: <list-10440250@EXECDSL.COM>
Message-ID: <a06200702beb78ab83528@[10.31.32.74]>

FWIW -

>  http://www.net.informatik.tu-muenchen.de/~anja/feldmann/papers/dnssec05.pdf

Eudora thinks that this is a "deceptive" URL because (apparently) 
"tu" is a TLD and it appears in the middle of the host name above.  I 
love false hits. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.


From galvin at elistx.com  Mon May 23 21:25:18 2005
From: galvin at elistx.com (James M Galvin)
Date: Mon, 23 May 2005 21:25:18 -0400
Subject: meeting announcement: 25 May 2005
Message-ID: <D2EBB2EB5267B2BF9AC0FD12@[10.0.0.4]>

This meeting will be held at the usual time of:

    1200 Los Angeles, San Francisco
    1200 Phoenix
    1500 Washington
    1900 UTC
    2100 Netherlands
    2200 Israel
    0400 Tokyo (the next day)
    0500 Melbourne (the next day)

The usual teleconference logistics are as follows.  These do not change.
You will hear music until the moderator joins (that would be me).

    USA Toll Free Number: +1 888-221-7341
    USA Toll Number:      +1 973-935-2305

    Passcode: 599786
    Leader:   James Galvin
	      employed by ICANN if speaking to an operator

    Jabber:   dnssec-deployment at conference.jabber.org
	      This is a public room.

    If your phone does not have a mute capability you can use "*6" to
    mute and unmute your connection.

    DIAL OUT:
        1. ISC SIP Bridge - contact me for SIP identifiers


DRAFT AGENDA

 - Managing secure entry points and transitioning to a signed parent

   In an ideal deployment there would be a very low barrier to entry, an
   enterprise could sign its zone and get immediate external benefit
   from having done so, a parent (e.g., a TLD) would sign its zone
   shortly thereafter, and the transition to inclusion in the larger
   infrastructure would be straightforward if not transparent.

   A concern is the tension between an orderly, top-down deployment:

       sign the root
       sign the TLDs
       sign the second level zones
       etc.

   And a bottoms-up, islands of trust deployment:

       enterprises sign their zones
       enterprises "distribute" their public key
       when the parent is ready the public key is "moved up"
       etc.

   The tension arises from wondering if the trust models will converge
   into a single, trusted infrastructure, i.e., if second-level zones
   can proceed without their TLDs, will there be sufficient motivation
   for the TLDs to sign their zones?

   This concern is related to three of the 11 issues listed in the
   DNSSEC Deployment Roadmap:


     2. Timing of signing the root zone and/or management of islands of
        trust

     A DNSSEC signed zone operating without a signed delegation from
     their parent zone is commonly called an 'island of trust'; this
     issue deals with questions that arise when zones are signed but the
     root is not.

     This issue addresses non-root trust anchors.  At last reporting (16
     February 2005) there was a DNSOP document in last call that spoke
     to this issue.


     3. Root key rollover and distribution

     Procedures for initial distribution of the root public key,
     periodic rollover of the public key, and its distribution

     This issue addresses root trust anchors.  It is largely similar to
     Issue 2 but because it is the root you probably want a separate
     document so you can say more about security.  And, unfortunately,
     there are political issues.  The root is just another trust anchor
     but it is a "special" one.  Changing the root key will have an
     impact just in pure numbers, as compared to any other trust anchor.


     4. Trust anchor key rollover and distribution

     Procedures for initial distribution of the trust anchor public key,
     periodic rollover of the public key, and its distribution; needed
     in Isolated, Sparse or Dense deployment, or for some applications.

     This issue addresses trust anchors in general.  There are some
     issues that go with a secure apex based on a spectrum of how much
     you care.


 - When can we have a technical workshop?

   During our last meeting we deferred most of the discussion of what to
   cover and when to hold a technical or interoperability workshop.  It
   was briefly noted that the RIPE Amsterdam meeting had the advantage
   of giving developers more time to prepare as compared to the IETF
   Paris meeting.  The suggested topic to cover in the workshop is the
   interoperability of epsilon implementations.



From olaf at ripe.net  Tue May 24 03:18:35 2005
From: olaf at ripe.net (Olaf M. Kolkman)
Date: Tue, 24 May 2005 09:18:35 +0200
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <list-10557307@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM>
Message-ID: <20050524091835.7efb8fca.olaf@ripe.net>


I have obligations elsewhere so I will not be able to join.

For what it is worth I have a strong deja-vu feeling when looking at the agenda. Are there recent developments that we should be aware off?



-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org


From rdroms at cisco.com  Tue May 24 07:49:43 2005
From: rdroms at cisco.com (Ralph Droms)
Date: Tue, 24 May 2005 07:49:43 -0400
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <list-10557307@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM>
Message-ID: <1116935383.8027.4.camel@localhost.localdomain>

I will be driving to the Denver airport at the time of the meeting this
week.  I may try to listen in via cell phone.

- Ralph


From weiler+lists.dnssec-deploy at watson.org  Tue May 24 11:32:25 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Tue, 24 May 2005 08:32:25 -0700 (PDT)
Subject: [dnssec-deployment] an academic study on resource usage
In-Reply-To: <list-10440250@EXECDSL.COM>
References: <list-10440250@EXECDSL.COM>
Message-ID: <20050524082714.E49603@fledge.watson.org>

> http://www.net.informatik.tu-muenchen.de/~anja/feldmann/papers/dnssec05.pdf

Here's my take on the paper.  I'd welcome others' thoughts, though I'm
not pushing anyone to read it.

There are two substantive parts of the paper: an paper analysis of
packet/bandwidth growth and an experimental analysis of CPU usage and
answer latency.  Both parts compare a non-DNSSEC world to a
completely-DNSSEC world in which _all_ data is signed.

Part 1: packet/bandwidth growth

Even though they're using "real" DNS data sets, these are non-DNSSEC 
data sets, and they're using handwaving and calculations to estimate 
what packet sizes would be if DNSSEC were turned on.  That misses any 
changes to the query stream which might be caused by DNSSEC, such as 
looking for missing DS records, etc.  It also misses any 
hard-to-predict effects of DNSSEC.

Given these caveats, the interesting bit is table 4, which shows, 
given their assumptions, what percentages of packets fit within 
cerrtain size bounds.  Since overflowing the UDP limit can result in 
delay or unreachability, this is important stuff, but it's not clear 
that their analysis tells us much.  They assume only one algorithm is 
in use at a time, certain key lengths (1200 bit RSA KSK, 1024 bit RSA 
ZSKs) and fixed numbers of keys in apex DNSKEYsets, which may not be 
realistic -- some rollover scenarios involve larger apex DNSKEYsets, 
at least for a time.

Part 2: CPU and latency

This experiment is very unrealistic, but it does show that resolver
CPU usage grows only by a factor of two when doing validation of all
answers, under some key length assumptions that they don't tell us
about.  The latency numbers in this experiment aren't credible, since
they're operating on a local area network and don't analyze exactly
what contributes to the delays - if they're doing lots of round trips
to different auth servers, real network delays could give very
different results.

They don't give many details, and there could also be odd effects from 
having ancestor zones share auth servers -- I'm not completely 
comfortable with the set-up.  They do say that resolver memory needs 
grow substantially, which we may not have thought much about.

Summary:

As their own summary says very well, they didn't find any showstoppers
to deployment.  Their experiments may not be realistic, but they
certainly didn't show anything surprising.

Details:

Note that one author, Bernhard Ager, cites his own thesis on
"Performance Evaluation of DNSSEC", dated 2005.  [11]

The last paragraph of section 5 shows a misunderstanding of the DO
bit semantics.

The right hard chart of Figure 1 is sort of cool -- the lines are
separated vertically by 174 bytes, the size of an RRSIG RR. (see the
second column of page 4 for discussion).  They claim the slope of the
lines is about 1 "due to the content of the orignal DNS packets".
Remember, though, that these are handwaving transformations, not
measured data.


From weiler+lists.dnssec-deploy at watson.org  Tue May 24 11:43:41 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Tue, 24 May 2005 08:43:41 -0700 (PDT)
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <list-10557307@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM>
Message-ID: <20050524083309.G49603@fledge.watson.org>

> DRAFT AGENDA
>
> - Managing secure entry points and transitioning to a signed parent

While this is a very interesting topic, one many of us have put 
significant energy into, I'm not clear on the goals of this 
discussion.  What, exactly, are you hoping we'll accomplish?  Can you 
refine the questions you want us to answer?

-- Sam


From steve at shinkuro.com  Tue May 24 12:30:27 2005
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 24 May 2005 12:30:27 -0400
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <list-10568529@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
Message-ID: <429356A3.5070801@shinkuro.com>

Sam Weiler wrote:
>>DRAFT AGENDA
>>
>>- Managing secure entry points and transitioning to a signed parent
> 
> 
> While this is a very interesting topic, one many of us have put 
> significant energy into, I'm not clear on the goals of this 
> discussion.  What, exactly, are you hoping we'll accomplish?  Can you 
> refine the questions you want us to answer?
> 
> -- Sam
> 

Fair question. Let me elaborate.  I'll write in the first person because 
  I have been giving this some thought myself and I'm not just 
reflecting the thoughts of others, but others -- Suzanne, Russ and 
probably others -- have also weighed in on this in various ways.

In looking at how the deployment process will unfold, I see a potential 
bottleneck when enterprises start to adopt DNSSEC.  Each enterprise will 
create a public-private key pair and they need to make its public key 
available to others.  If the parent zone, i.e. its TLD, is ready to 
accept keys and serve them within the zone, that's fine.  If not, the 
enterprise needs to find some other way to make those keys available. 
(Or, it could just give up ;)

It's my understanding that at present, we do not have any well 
orchestrated mechanism in place for enterprises to make their keys 
available in the absense of the TLD.  ISC's DLV mechanism is perhaps the 
furthest along, but we don't have any experience with it, nor do have 
broad agreement that that's the right thing to do.

The wording in the basic documents suggest it's private matter how to 
distribute keys when the TLD is not ready.

One argument against providing a separate mechanism is that it might 
become too successful and effectively retard the eventual full 
deployment of DNSSEC throughout the hierarchy.

I believe we need a well defined and effective means for enterprises to 
distribute their keys when they're ready, even if the parent TLD is not 
yet ready, but the overall system has to encourage and facilitate 
adoption throughout the hierarchy.  This is not a trivial challenge and 
it won't come along without some thought and implementation, but I also 
think it's entirely feasible.  Let me press on a bit more.

Suppose an enterprise installs DNSSEC software and puts it into 
operation.  It generates its public-private key pair and then looks for 
a method of making its public key available.

If the TLD is ready, then it sends the key to the TLD, either via its 
registrar if the TLD uses registrars, or directly if the TLD deals 
directly registrants.

However, if the TLD is not ready, the enterprise has to choose some 
other means.  I think it would be very helpful if there were a way for:

o The enterprise to make its key available through a well defined store 
of secure entry points, AND

o Once the parent TLD becomes signed, there were a transition of those 
keys out of the store of secure entry points and into the TLD.

So far as I know, no one has sketched out, much less implemented, how to 
make this process work.

My current thinking is that this is actually a pivotal piece of the 
plan.  If we get this part right, we can encourage enterprises to adopt 
DNSSEC, it will be useful when they do, there will be smooth transition 
to "regular" operation when the TLD is ready, and thus it will encourage 
the TLDs to adopt DNSSEC whenever they see their registrants adopting it.

A similar argument can be applied to the relationship between TLDs and 
the root in the event the root doesn't get ready in time to handle the 
keys from the TLD, but I fervently hope the root is indeed ready. 
However, there are 258 TLDs the last time I looked, and most will not be 
ready for DNSSEC before their first registrants are.

Returning to your message, "What, exactly, are you hoping we'll 
accomplish?  Can you refine the questions you want us to answer?":

1. Discussion within the group of whether we're in agreement that an 
organized mechanism for conveyance (and use!) of public keys is needed 
in the event the TLD is not ready.

2. Discussion of how such a mechanism will interact with subsequent 
deployment by the TLD, e.g. retard, advance, transition smoothly, 
require double work, etc.

3. Discussion of whether more design work is needed.

4. If agreement is reached on the basic ideas, then a specific plan is 
needed.


Steve



From mlarson at verisign.com  Tue May 24 13:24:37 2005
From: mlarson at verisign.com (Matt Larson)
Date: Tue, 24 May 2005 13:24:37 -0400
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <list-10569089@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM>
Message-ID: <20050524172437.GP17267@chinook.corpit.vrsn.com>

On Tue, 24 May 2005, Steve Crocker wrote:
> I believe we need a well defined and effective means for enterprises to 
> distribute their keys when they're ready, even if the parent TLD is not 
> yet ready, but the overall system has to encourage and facilitate 
> adoption throughout the hierarchy.  This is not a trivial challenge and 
> it won't come along without some thought and implementation, but I also 
> think it's entirely feasible.  Let me press on a bit more.

There are some problems with such a scheme:

- Can validator implementations support the hundreds or thousands of
  trust anchors that would potentially result from such a scheme?

- How will these trust anchors be authenticated in this key store
  outside of the DNSSEC chain of trust?  (They have to be
  authenticated both going in and coming out, i.e., registration and
  distribution.)

- How will the keys be kept fresh once configured in validators
  throughout the Internet?  (I would never put my zone's key in such a
  store unless there were some reliable mechanism to keep it from
  getting stale, which is unlikely without a lot of additional work.)

All of these problems can be overcome with careful engineering, but is
it worth it?  I think our time is better spent on removing other
obstacles to deployment: Let's get the root signed.  Let's get NSEC3
out the door so registries with privacy and/or resource concerns can
deploy.  Let's work on operational documents.  But let's be careful
before we start down a path of trying to distribute and maintain lots
of trust anchors.

Matt


From steve at shinkuro.com  Tue May 24 15:17:56 2005
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 24 May 2005 15:17:56 -0400
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <20050524172437.GP17267@chinook.corpit.vrsn.com>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com>
Message-ID: <42937DE4.9000406@shinkuro.com>



Matt Larson wrote:
> On Tue, 24 May 2005, Steve Crocker wrote:
> 
>>I believe we need a well defined and effective means for enterprises to 
>>distribute their keys when they're ready, even if the parent TLD is not 
>>yet ready, but the overall system has to encourage and facilitate 
>>adoption throughout the hierarchy.  This is not a trivial challenge and 
>>it won't come along without some thought and implementation, but I also 
>>think it's entirely feasible.  Let me press on a bit more.
> 
> 
> There are some problems with such a scheme:
> 
> - Can validator implementations support the hundreds or thousands of
>   trust anchors that would potentially result from such a scheme?

It would be really great to get a reasonable estimate on how big this 
number will actually be.  My guess is that hundreds or thousands is 
fine.  What happens if the number grows to tens or hundreds of thousands?

> - How will these trust anchors be authenticated in this key store
>   outside of the DNSSEC chain of trust?  (They have to be
>   authenticated both going in and coming out, i.e., registration and
>   distribution.)

Well, this is at the heart of the whole concept of having a separate 
store.  This certainly needs some sort of acceptable answer.

> - How will the keys be kept fresh once configured in validators
>   throughout the Internet?  (I would never put my zone's key in such a
>   store unless there were some reliable mechanism to keep it from
>   getting stale, which is unlikely without a lot of additional work.)

Good question.  I have some thoughts on this, but I will hold them for 
one round.

> All of these problems can be overcome with careful engineering, but is
> it worth it?  I think our time is better spent on removing other
> obstacles to deployment: Let's get the root signed.  Let's get NSEC3
> out the door so registries with privacy and/or resource concerns can
> deploy.  Let's work on operational documents.  But let's be careful
> before we start down a path of trying to distribute and maintain lots
> of trust anchors.

I completely agree we want to remove the barriers.  Getting the root 
signed is very high on the list.  The NSEC problem is also high on the 
list.  Whether we can hustle NSEC3 fast enough is more problematical.  I 
would not let up any pressure on these at all.

That said, I think it's inevitable that we have to find a way for an 
enterprise to proceed before its parent TLDs is signed and ready to 
serve its children.  To me, this is a key point, and this is a good time 
discuss it and determine whether we're in agreement on it.  I can 
understand the alternative point of view and I don't want to dismiss it. 
  I just think it's not the right bet.  Of course, it will indeed take 
time and energy to deal with the incremental deployment.  My believe is 
we simply need to do so.  But we need to get broader agreement and 
clarity of direction.

Steve


> 
> Matt
> 


From paul at vix.com  Tue May 24 15:41:02 2005
From: paul at vix.com (Paul Vixie)
Date: Tue, 24 May 2005 19:41:02 +0000
Subject: [dnssec-deployment] meeting announcement: 25 May 2005 
In-Reply-To: Your message of "Tue, 24 May 2005 12:30:27 -0400."
             <list-10569089@EXECDSL.COM> 
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>  <list-10569089@EXECDSL.COM> 
Message-ID: <20050524194102.535D014D5C@sa.vix.com>

An embedded and charset-unspecified text was scrubbed...
Name: isc-tn-2004-2.txt
Url: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20050524/f33f64bb/attachment.txt 

From weiler+lists.dnssec-deploy at watson.org  Tue May 24 15:44:49 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Tue, 24 May 2005 12:44:49 -0700 (PDT)
Subject: NSEC3 progress (was: Re: [dnssec-deployment] meeting announcement:
 25 May 2005)
In-Reply-To: <42937DE4.9000406@shinkuro.com>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
 <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com>
 <42937DE4.9000406@shinkuro.com>
Message-ID: <20050524123805.Q65329@fledge.watson.org>

On Tue, 24 May 2005, Steve Crocker wrote:

> The NSEC problem is also high on the list. Whether we can hustle 
> NSEC3 fast enough is more problematical.  I would not let up any 
> pressure on these at all.

It looks to me like we already have let up the pressure.  Or, perhaps 
more correctly, the proponents of NSEC3 have let up the pressure. 
The last NSEC3 draft revision came out over three months ago, and 
there hasn't been a peep about it on the list[1] since April 1st.

That says to me that people don't care very much.  Perhaps the 
proponents of it have decided that the epsilon approach is sufficient,
or they simply don't want to do DNSSEC at all?

-- Sam

[1] By "the list", I mean namedroppers.


From paul at vix.com  Tue May 24 15:45:50 2005
From: paul at vix.com (Paul Vixie)
Date: Tue, 24 May 2005 19:45:50 +0000
Subject: [dnssec-deployment] meeting announcement: 25 May 2005 
In-Reply-To: Your message of "Tue, 24 May 2005 13:24:37 -0400."
             <list-10569958@EXECDSL.COM> 
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM>  <list-10569958@EXECDSL.COM> 
Message-ID: <20050524194550.EE3DE14D5C@sa.vix.com>

> There are some problems with such a scheme:

let me answer for DLV.

> - Can validator implementations support the hundreds or thousands of
>   trust anchors that would potentially result from such a scheme?

yes.

> - How will these trust anchors be authenticated in this key store
>   outside of the DNSSEC chain of trust?  (They have to be authenticated
>   both going in and coming out, i.e., registration and distribution.)

the DLV documents and technology produced to date don't cover registration.

for distribution, DLV relies on a static (nonrolling) trust anchor similar
to the one needed to authenticate the root zone signing key.

> - How will the keys be kept fresh once configured in validators
>   throughout the Internet?  (I would never put my zone's key in such a
>   store unless there were some reliable mechanism to keep it from
>   getting stale, which is unlikely without a lot of additional work.)

dlv does not statically distribute keys.  staleness is controlled with TTL,
SOA timers, signature lifetimes, and other normal secure authoritative DNS 
features.

> All of these problems can be overcome with careful engineering, but is
> it worth it?  I think our time is better spent on removing other
> obstacles to deployment: Let's get the root signed.  Let's get NSEC3
> out the door so registries with privacy and/or resource concerns can
> deploy.  Let's work on operational documents.  But let's be careful
> before we start down a path of trying to distribute and maintain lots
> of trust anchors.

speaking for dnssec-deployment@, i tend to agree.

speaking independently, DLV is already in my plans.


From steve at shinkuro.com  Tue May 24 16:25:52 2005
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 24 May 2005 16:25:52 -0400
Subject: NSEC3 progress
In-Reply-To: <20050524123805.Q65329@fledge.watson.org>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <20050524123805.Q65329@fledge.watson.org>
Message-ID: <42938DD0.9090808@shinkuro.com>

Well, this seems a tad harsh.  But I too am curious what the progress is 
on NSEC3 and whether there is a nominal schedule that we can pay 
attention to.

Steve

Sam Weiler wrote:
> On Tue, 24 May 2005, Steve Crocker wrote:
> 
>> The NSEC problem is also high on the list. Whether we can hustle NSEC3 
>> fast enough is more problematical.  I would not let up any pressure on 
>> these at all.
> 
> 
> It looks to me like we already have let up the pressure.  Or, perhaps 
> more correctly, the proponents of NSEC3 have let up the pressure. The 
> last NSEC3 draft revision came out over three months ago, and there 
> hasn't been a peep about it on the list[1] since April 1st.
> 
> That says to me that people don't care very much.  Perhaps the 
> proponents of it have decided that the epsilon approach is sufficient,
> or they simply don't want to do DNSSEC at all?
> 
> -- Sam
> 
> [1] By "the list", I mean namedroppers.
> 


From davidb at verisignlabs.com  Tue May 24 16:34:21 2005
From: davidb at verisignlabs.com (David Blacka)
Date: Tue, 24 May 2005 16:34:21 -0400
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10571752@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM>
Message-ID: <42938FCD.6090307@verisignlabs.com>

Sam Weiler wrote:
> On Tue, 24 May 2005, Steve Crocker wrote:
> 
> 
>>The NSEC problem is also high on the list. Whether we can hustle 
>>NSEC3 fast enough is more problematical.  I would not let up any 
>>pressure on these at all.
> 
> 
> It looks to me like we already have let up the pressure.  Or, perhaps 
> more correctly, the proponents of NSEC3 have let up the pressure. 
> The last NSEC3 draft revision came out over three months ago, and 
> there hasn't been a peep about it on the list[1] since April 1st.
> 
> That says to me that people don't care very much.  Perhaps the 
> proponents of it have decided that the epsilon approach is sufficient,
> or they simply don't want to do DNSSEC at all?

 From a conversation that I had with Jay Daley of Nominet in Stockholm, 
it was pretty clear that they are still quite interested in NSEC3.

As to why there hasn't been a new NSEC3 draft published, I cannot say. 
There is an update due, as I understand it.

-- 
David Blacka    <davidb at verisignlabs.com>
Sr. Engineer    VeriSign Applied Research


From paul at vix.com  Tue May 24 16:39:53 2005
From: paul at vix.com (Paul Vixie)
Date: Tue, 24 May 2005 20:39:53 +0000
Subject: [dnssec-deployment] NSEC3 progress 
In-Reply-To: Your message of "Tue, 24 May 2005 16:25:52 -0400."
             <list-10572394@EXECDSL.COM> 
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <20050524123805.Q65329@fledge.watson.org>  <list-10572394@EXECDSL.COM> 
Message-ID: <20050524203953.6A9D814D5C@sa.vix.com>

> Perhaps the proponents of it have decided that the epsilon approach is
> sufficient, or they simply don't want to do DNSSEC at all?

the right person to ask (ben laurie) probably should be on this mailing list,
but as far as i know, is not.  he's <ben at algroup.co.uk> if that matters.

> Well, this seems a tad harsh.  But I too am curious what the progress is on
> NSEC3 and whether there is a nominal schedule that we can pay attention to.

the reaction from within ietf to the concerns and proposals of the NSEC3
community has been dishearteningly underwhelming.  noone, it seems, wants
to see this can of worms opened again, or at least, not so soon.


From roy at dnss.ec  Tue May 24 17:35:20 2005
From: roy at dnss.ec (Roy Arends)
Date: Tue, 24 May 2005 23:35:20 +0200 (CEST)
Subject: [dnssec-deployment] NSEC3 progress (was: Re: [dnssec-deployment]
 meeting announcement: 25 May 2005)
In-Reply-To: <list-10571752@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
 <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com>
 <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM>
Message-ID: <Pine.BSO.4.56.0505242320550.21142@trinitario.schlyter.se>

On Tue, 24 May 2005, Sam Weiler wrote:

> On Tue, 24 May 2005, Steve Crocker wrote:
>
> > The NSEC problem is also high on the list. Whether we can hustle
> > NSEC3 fast enough is more problematical.  I would not let up any
> > pressure on these at all.
>
> It looks to me like we already have let up the pressure.  Or, perhaps
> more correctly, the proponents of NSEC3 have let up the pressure.
> The last NSEC3 draft revision came out over three months ago, and
> there hasn't been a peep about it on the list[1] since April 1st.
>
> That says to me that people don't care very much.  Perhaps the
> proponents of it have decided that the epsilon approach is sufficient,
> or they simply don't want to do DNSSEC at all?

We're pretty busy with NSEC3. We've got a lot of support from folk from
several areas in the field.  As I understand it they see NSEC3 as an
alternative to epsilon since the epsilon approach needs an online private
key, and has some denial of service vectors.  Two issues that some
consider showstoppers. To these folks, the enumerability is a showstopper
as well.

We'll definitly make the drafts deadline for the upcoming ietf.

Meanwhile, I don't think the approaches (NSEC3 or epsilon) are mutually
exclusive. Both have its merits, its application, its issues. Lets just
work on this to make them both technically sound, so one has a choice.

Roy Arends


From weiler+lists.dnssec-deploy at watson.org  Tue May 24 17:43:10 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Tue, 24 May 2005 14:43:10 -0700 (PDT)
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <20050524172437.GP17267@chinook.corpit.vrsn.com>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
 <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com>
Message-ID: <20050524112523.X49603@fledge.watson.org>

As long as we're talking about specific trust anchor distribution 
schemes, Ben Laurie proposed an out-of-band scheme last fall:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01860.html

At the time, I called it "a very good approach":
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01873.html

-- Sam


From weiler+lists.dnssec-deploy at watson.org  Tue May 24 18:11:27 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Tue, 24 May 2005 15:11:27 -0700 (PDT)
Subject: [dnssec-deployment] meeting announcement: 25 May 2005 
In-Reply-To: <list-10571715@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> 
 <list-10569089@EXECDSL.COM>  <list-10571715@EXECDSL.COM>
Message-ID: <20050524145732.M66769@fledge.watson.org>

I don't think this list is the best place to discuss technical
details, but I suppose it will do for the moment.  I think the ISC
tech note has some weaknesses, and I've been attempting to address
them in my own DLV specification, which I've attached.  The ISC tech
note has a "do not redistribute" header on it -- I feel no need for
such restrictions on mine.

I would really appreciate critical review of this spec.  In 
particular, I'd like answers to the following questions:

1) Is this spec readable and complete?  What needs to be cleaned up?

2) Is it convincing?  What questions or doubts are you left with after
reading it?

3) Should the name DLV be changed?  This document has some small 
differences from what Paul's paper and the ISC tech note describe. 
Is there another name which would provide more comfort and reassurance 
to potential users of the technique?

As for the technical details: it looks like the DLV selection/search
algorithm described in section 4.2 of the ISC tech note is the same as
the "closest encloser trumps" algorithm I described in [1].
Unfortunately, this algorithm turns the DLV domain's authoritative
servers into Uber-resolvers -- modulo aggressive negative caching,
every unique DNS query from every DLV-capable resolver hits the DLV
servers.  As I read the ISC tech note, even if the root is signed and
the DLV domain publishes a DLV entry for the root, every query will
still hit the DLV servers (again, modulo aggressive negative caching).

The DLV selection/search algorithm described in the attached doc 
(which is similar to the "accept any success" algorithm from [1]) does 
not have that problem.  If there's a DLV RR for the root and the 
validation chain from the root to each QNAME works, the DLV servers 
will only get one query per resolver per TTL (for the root DLV entry).

-- Sam

[1] Weiler, S.  Deploying DNSSEC Without a Signed Root.
     Technical Report 1999-19, Information Networking
     Institute, Carnegie Mellon University, April 2004.
     http://www.watson.org/~weiler/INI1999-19.pdf
-------------- next part --------------
	                                                      S. Weiler
                                                            22 May 2005

		      DNSSEC Lookaside Validation (DLV)
		      draft-weiler-dnssec-dlv-pre00.txt

Copyright Notice

   Copyright (C) Samuel Weiler (2005).

Abstract

   DNSSEC Lookaside Validation (DLV) is a mechanism for publishing
   DNSSEC trust anchors outside of the DNS delegation chain.  It
   allows resolvers to validate DNSSEC-signed data from zones whose
   ancestors either aren't signed or refuse to publish DS records for
   their children.

1.  Introduction

   DNSSEC [RFC4033] authenticates DNS data by building public-key
   signature chains along the DNS delegation chain from a root of
   trust, ideally the DNS root.  Due to a myriad of technical and
   political concerns, it appears unlikely that many delegation-heavy
   zones, including the root and most generic top level domains
   (gTLDs), will sign their zones in the near future, which leaves DNS
   resolvers with no means to validate data from the children of those
   zones without maintaining a large number of preconfigured keys.

   This document describes a way to publish trust anchors in the DNS
   but outside of the normal delegation chain.

   Some design trade-offs leading to the mechanism presented here are
   described in [INI19].

2.  Architecture

   DNSSEC Lookaside Validation allows a set of well-known domains,
   called "DLV domains", to publish secure entry points for zones that
   are not their own children.

   With DNSSEC, validators may expect a zone to be secure when they
   have one of two things: a preconfigured trust anchor for the zone
   or a validated DS for the zone in its parent.  DLV adds a third
   mechanism: an entry in a DLV domain.  Whenever a DLV domain
   publishes a DLV RRset for a zone, a resolver may expect the named
   zone to be signed.  Absence of a DLV RRset for a zone does not
   necessarily mean that the zone should be expected to be insecure;
   if the resolver has another reason to believe the zone should be
   secured, validation of that zone's data should still be attempted.

3.  DLV Domains

   A DLV domain includes trust statements about descendants of a single
   zone, called the 'target' zone.  For example, the DLV domain
   trustbroker.example.com could target the .org zone and the DLV
   domain bar.example.com could target the root.

   A DLV domain contains one or more DLV records for each of the
   target's descendant zones that have registered security information
   with it.  For a given zone, the corresponding name in the DLV
   domain is formed by replacing the target zone name with the DLV
   domain name.  For example, assuming the DLV domain
   trustbroker.example.com targets the .org zone, any DLV records for
   the zone example.org can be found at
   example.trustbroker.example.com.  DLV records for the org zone can
   be found at the apex of trustbroker.example.com.

   A DLV domain SHOULD NOT contain data other than DLV records,
   appropriate DNSSEC records validating that data, the apex NS and
   SOA records, and, optionally, delegations.

   To gain full benefit from aggressive negative caching, described in
   Section 6, a DLV domain SHOULD NOT use minimally-covering NSEC
   records, as described in [EPSILON].

4.  DLV Resource Record

   The DLV resource record has exactly the same wire and presentation
   formats as the DS resource record, defined in [RFC4034] and
   RFC3658.  It uses the same IANA-assigned values in the algorithm
   and digest type fields as the DS record.  (Those IANA registries
   are known as the "DNS Security Algorithm Numbers" and "DS RR Type
   Algorithm Numbers" registries.)

   Unlike the DS record, the DLV record MUST NOT appear on the
   parent's side of a zone cut.  Consequently, DLV records to not
   require the special processing described in section 2.2.1 of
   RFC3658.  DLV records MAY appear at the apex of a zone.

5.  Resolver Behavior, Overview

   When configured with a trust anchor for a DLV domain, a resolver
   SHOULD attempt to validate all queries at and below the target of
   that DLV domain.

   To do validation using DLV, a resolver looks for a (validated) DLV
   RRset applicable to the query and uses it as though it were a DS
   RRset to validate the answer using the normal procedures in RFC4035
   Section 5.

   The resolver continues to search for applicable DLV RRsets and
   attempt validation using them until either the answer is validated
   as Secure or all possible applicable DLV records have been checked.
   If any of the applicable DLV records led to a Secure result, the
   answer is treated as Secure.  If all of the DLV records led to
   Insecure validation results, the answer is treated as Insecure.
   And if no DLV records led to Secure results and at least one led to
   a Bogus result, the answer is treated as Bogus.

   The choice of which DLV record(s) to use, and in what order, has a
   significant impact on the query load seen at DLV domain
   authoritative servers.  Consequently, resolvers are advised to
   closely follow the algorithm in the following section.  More
   detailed discussion of this algorithm and other possible choice can
   be found in [INI19].

5.1  Resolver Behavior, Detail

   To minimize load on the DLV domain's authoritative servers as well
   as query response time, a resolver SHOULD accept any Secure
   validation result (as described in RFC4035 Section 4.3) as decisive
   and SHOULD NOT attempt to exhaustively search for all possible DLV
   RRsets applicable to the QNAME after a Secure result has been
   found.  Furthermore, the resolver SHOULD use cached DLV RRsets and
   careful choice of queries to attempt to find a Secure validation
   result with the minimum number of queries to the DLV domain.

   Accordingly, a resolver SHOULD first attempt validation using any
   applicable (non-DLV) trust anchors.  If the validation succeeds
   (with a result of Secure), DLV processing need not occur.

   If other (non-DLV) trust anchors failed to yield a Secure
   validation result, a resolver SHOULD then attempt to use any
   applicable cached DLV RRsets.  For clarity, it may be possible for
   several DLV RRsets within a single DLV domain to be applicable to
   a given QNAME.  Using the previous example of the bar.example.com
   DLV domain targeting the root and a QNAME of www.example.org,
   there could be four DLV RRsets of relevance:
      -- a DLV RRset at bar.example.com corresponding to the root's
         DNSKEY(s),
      -- a DLV RRset at org.bar.example.com,
      -- a DLV RRset at example.org.bar.example.com, and
      -- a DLV RRset at www.example.org.bar.example.com.

   If none of the cached DLV RRsets leads to a Secure result (or there
   are no applicable cached DLV RRsets), the resolver queries the DLV
   domain to attempt to find another of the applicable DLV RRsets.  To
   minimize the number of queries to the DLV zone, it is suggested
   that the resolver start with a query for the least specific
   applicable DLV RRset (the one with the fewest labels), then
   progress to longer names.  Section 8 discusses a slightly different
   strategy.

   Having found an applicable DLV RRset or received a proof that the
   requested record doesn't exist, the resolver MUST validate that
   RRset or non-existence proof using the normal procedures in Section
   5 of RFC4035.  In particular, any delegations within the DLV domain
   need to be followed, with normal DNSSEC validation applied.  If
   validation of the DLV RRset leads to a result of Insecure (the DLV
   record is in an unsecured portion of the DLV tree), then it SHOULD
   NOT be used.  If the validation of the DLV RRset leads to a result
   of Secure, then resolver then treats that DLV RRset as though it
   were a DS RRset for the applicable zone and attempts validation
   using the procedures described in RFC4035 Section 5.  If any such
   validation returns a Secure result, the answer is treated as Secure
   and DLV processing ends.  Otherwise, the resolver continues to
   query for other applicable DLV RRsets until a Secure validation
   results or all applicable DLV RRsets have been exhausted.

   To avoid confusing authors of resolvers and protocol
   specifications, a resolver SHOULD NOT attempt to validate data from
   a DLV domain using DLV.

6.  Aggressive Negative Caching

   To minimize load on authoritative servers for DLV domains,
   particularly those with few entries, DLV resolvers SHOULD implement
   aggressive negative caching, as defined in this section.

   Previously, cached negative responses were indexed by QNAME,
   QCLASS, QTYPE, and the setting of the CD bit (see RFC4035 section
   4.7) and only queries matching the index would be answered from the
   cache.  With aggressive negative caching, the resolver, in addition
   to checking to see if the answer is in its cache before sending a
   query, checks to see whether any cached and validated NSEC record
   denies the existence of the sought record(s).

   Using aggressive negative caching, a resolver will not make
   queries for any name covered by a cached and validated NSEC record.
   Furthermore, a resolver answering queries from clients will
   synthesize a negative answer whenever it has an applicable
   validated NSEC in its cache [unless the CD bit was set on the
   incoming query?].

7.  Overlapping DLV Domains

   It is possible to have multiple DLV domains targeting overlapping
   portion of the DNS hierarchy.  For example, two DLV domains,
   perhaps operated by different parties, might target the same zone,
   or one DLV domain might target the root while another targets .org.

   The choice of precedence in these cases is left up to the
   implementation and MAY be exposed as a configuration option to the
   user.  As a default, it is suggested that the most specific DLV
   domain be given precedence.

8.  Optimization

   This section proposes an immature and untested proposed
   optimization to further reduce query load on DLV servers.

   Resolver side: resolvers, when making a DLV query, should ask for
   the most specific DLV record first.

   Authoritative server side: authoritative servers, when processing a
   DLV query, should include all DLV RRsets potentially applicable to
   a query in the Additional[???] section of the response as well as
   NSEC records proving the non-existence of any other applicable
   DLV records with the DLV domain.

   This optimization may preclude the use the delegations within a DLV
   domain.

9.  Security Considerations

   Resolvers MUST NOT use a DLV record unless it has been successfully
   authenticated.  Normally, resolvers will have a trust anchor for
   the DLV domain and use DNSSEC to validate the data in it.

   Aggressive negative caching increases the need for resolvers do
   some basic validation of incoming NSEC records before caching them.
   In particular, the 'next name' field in the NSEC record must be
   within the zone that generated (and signed) the NSEC.  Otherwise, a
   malicious zone operator could generate an NSEC that reaches out of
   its zone -- into its ancestor zones, even up into the root zone --
   and use that NSEC to spoof away any name that sorts after the name
   of the NSEC.  We call these overreaching NSECs.  More insidiously,
   an attacker could use an overreaching NSEC in combination with a
   signed wildcard record to substitute a signed positive answer in
   place of the real data.  This checking is not a new requirement --
   these attacks are a risk even without aggressive negative caching.
   However, aggressive negative caching makes the checking more
   important.  Before aggressive negative caching, NSECs were cached
   only as metadata associated with a particular query.  An
   overreaching NSEC that resulted from a broken zone signing tool or
   some misconfiguration would only be used by a cache for those
   queries that it had specifically made before.  Only an overreaching
   NSEC actively served by an attacker could cause misbehavior.  With
   aggressive negative caching, an overreaching NSEC can cause more
   broader problems even in the absence of an active attacker.  This
   threat can be easily mitigated by checking the bounds on the NSEC.

   As a reminder, resolvers MUST NOT use the mere presence of an
   RRSIG or apex DNSKEY RRset as a trigger for doing validation,
   whether through the normal DNSSEC hierarchy or DLV.  Otherwise, an
   attacker might perpetrate a downgrade attack by stripping off those
   RRSIGs or DNSKEYs.

10.  IANA Considerations

   IANA has assigned DNS type code X to the DLV resource record from the
   Specification Required portion of the DNS Resource Record Type
   registry, as defined in RFC2929.

   The DLV resource record reuses the same algorithm and digest type
   registries already used for the DS resource record, currently known
   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
   Numbers" registries.

11.  References

   [INI19]    Weiler, S.  Deploying DNSSEC Without a Signed Root.
              Technical Report 1999-19, Information Networking
              Institute, Carnegie Mellon University, April 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and
              S. Rose, "DNS Security Introduction and Requirements",
	      RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and
	      S. Rose, "Resource Records for the DNS Security
	      Extensions", RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and
	      S. Rose, "Protocol Modifications for the DNS Security
	      Extensions", RFC 4035, March 2005.

   [EPSILON]  Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
	      and DNSSEC On-line Signing",
	      draft-ietf-dnsext-dnssec-online-signing-00 (work in
	      progress), May 2005.

Acknowledgements

   David Conrad is to blame for the general idea of off-tree
   publication of trust anchors.

   Paul Vixie, Suzanne Woolf, and Johan Ihren contributed
   significantly to the exploration of possible resolver algorithms
   that led to this design.  More about those explorations is
   documented in [INI19].

   Johan Ihren and the editor share the blame for aggressive negative
   caching.

From ben at algroup.co.uk  Tue May 24 18:32:57 2005
From: ben at algroup.co.uk (Ben Laurie)
Date: Tue, 24 May 2005 23:32:57 +0100
Subject: [dnssec-deployment] meeting announcement: 25 May 2005
In-Reply-To: <list-10573211@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <list-10573211@EXECDSL.COM>
Message-ID: <4293AB99.50807@algroup.co.uk>

Sam Weiler wrote:
> As long as we're talking about specific trust anchor distribution 
> schemes, Ben Laurie proposed an out-of-band scheme last fall:
> http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01860.html
> 
> At the time, I called it "a very good approach":
> http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01873.html

Thankyou. And just to add a comment, I've been _trying_ to get it
implemented, at least experimentally. I won't bother you with the litany
explaining why I've so far failed (other than to say that if all else
fails, I'll write it myself), but I do intend to have an implementation
Real Soon Now.

Cheers,

Ben.


From ben at algroup.co.uk  Tue May 24 18:37:43 2005
From: ben at algroup.co.uk (Ben Laurie)
Date: Tue, 24 May 2005 23:37:43 +0100
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10571752@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM>
Message-ID: <4293ACB7.6090405@algroup.co.uk>

Sam Weiler wrote:
> On Tue, 24 May 2005, Steve Crocker wrote:
> 
> 
>>The NSEC problem is also high on the list. Whether we can hustle 
>>NSEC3 fast enough is more problematical.  I would not let up any 
>>pressure on these at all.
> 
> 
> It looks to me like we already have let up the pressure.  Or, perhaps 
> more correctly, the proponents of NSEC3 have let up the pressure. 
> The last NSEC3 draft revision came out over three months ago, and 
> there hasn't been a peep about it on the list[1] since April 1st.
> 
> That says to me that people don't care very much.  Perhaps the 
> proponents of it have decided that the epsilon approach is sufficient,
> or they simply don't want to do DNSSEC at all?

It is not that we don't care. The situation is that we're working on a
new draft including what everyone has asked for: corrections of various
kinds, and much more importantly, worked examples and a clear
explanation of the at most three records needed to do a denial,
including wildcards.

This is a fair chunk of work. Expect an update.

It seems to me quite inappropriate to characterise the importance or
relevance of an approach by the amount of list bandwidth it uses up. We
believe in DNSSEC and NSEC3, we want it to happen, we don't want to
waste your time on considering half-baked versions of it.

Cheers,

Ben.


From weiler+lists.dnssec-deploy at watson.org  Tue May 24 18:55:29 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Tue, 24 May 2005 15:55:29 -0700 (PDT)
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10573695@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
 <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com>
 <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM>
Message-ID: <20050524154636.K65699@fledge.watson.org>

On Tue, 24 May 2005, Ben Laurie wrote:

> It seems to me quite inappropriate to characterise the importance or
> relevance of an approach by the amount of list bandwidth it uses up.

Probably so.  Please accept my apologies for misinterpreting the 
silence.  I'm very glad to hear that progress is being made, and I'm 
looking forward to reading the revision.

> ... we don't want to waste your time on considering half-baked 
> versions of it.

Thank you for your kind consideration.  I wish more editors of 
protocol specs displayed such restraint.

-- Sam


From paul at vix.com  Tue May 24 23:15:47 2005
From: paul at vix.com (Paul Vixie)
Date: Wed, 25 May 2005 03:15:47 +0000
Subject: [dnssec-deployment] meeting announcement: 25 May 2005 
In-Reply-To: Your message of "Tue, 24 May 2005 15:11:27 MST."
             <list-10573499@EXECDSL.COM> 
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <list-10571715@EXECDSL.COM>  <list-10573499@EXECDSL.COM> 
Message-ID: <20050525031547.6CB3514D5C@sa.vix.com>

> I don't think this list is the best place to discuss technical
> details, but I suppose it will do for the moment.

ok.  apparently we've all decided that early-deployment technology is
outside the interests (or capabilities?) of ietf, so here we are?

> I think the ISC tech note has some weaknesses, and I've been
> attempting to address them in my own DLV specification, ...

for the record, sam has raised these concerns about ISC's approach in
prior conversations, and he and i have agreed to politely disagree.

> ... I'd like answers to the following questions:
> ...
> 3) Should the name DLV be changed?  This document has some small
> differences from what Paul's paper and the ISC tech note describe.  Is
> there another name which would provide more comfort and reassurance to
> potential users of the technique?

also for the record, i have no opinion on sam calling his proposal DLV,
other than that it could confuse onlookers.

> As for the technical details: it looks like the DLV selection/search
> algorithm described in section 4.2 of the ISC tech note is the same as
> the "closest encloser trumps" algorithm I described in [1].

it certainly sounds similar.

> Unfortunately, this algorithm turns the DLV domain's authoritative
> servers into Uber-resolvers -- modulo aggressive negative caching,
> every unique DNS query from every DLV-capable resolver hits the DLV
> servers.  As I read the ISC tech note, even if the root is signed and
> the DLV domain publishes a DLV entry for the root, every query will
> still hit the DLV servers (again, modulo aggressive negative caching).
> 
> The DLV selection/search algorithm described in the attached doc
> (which is similar to the "accept any success" algorithm from [1]) does
> not have that problem.  If there's a DLV RR for the root and the
> validation chain from the root to each QNAME works, the DLV servers
> will only get one query per resolver per TTL (for the root DLV entry).

the reasons for this design choice are made clear in my various documents.

in any case my mind boggles at the idea of a DLV entry for the root itself.
if the root itself were signed, then the right way for a validator to use
signatures in that zone would be to have a static trust anchor for it, as
described in the DNSSEC-bis documents.  a signed root would be one of the
horseman of apocalypse for early deployment aids like DLV (any flavour).


From olaf at ripe.net  Wed May 25 07:01:12 2005
From: olaf at ripe.net (Olaf M. Kolkman)
Date: Wed, 25 May 2005 13:01:12 +0200
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10573695@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM>
Message-ID: <2B6319AF-971B-4A50-BDD1-349F97DFA1D7@ripe.net>


On May 25, 2005, at 12:37 AM, Ben Laurie wrote:

>
> It seems to me quite inappropriate to characterise the importance or
> relevance of an approach by the amount of list bandwidth it uses  
> up. We
> believe in DNSSEC and NSEC3, we want it to happen, we don't want to
> waste your time on considering half-baked versions of it.
>
>

For what its worth.

NSEC3 is on the groups agenda and I feel that after this update has  
been published we should make the jump from vapourware to software  
and organise a workshop to understand possible issues. In the past  
those workshops have shown to be more than worthwhile in getting good  
specs. Question: anybody doing an implementation, server/client side?

As far as I understand the "epsilon" work seems to be heading to non- 
deployment. I have not heard of anybody seriously planning on its  
deployment. I think it would be a shame to let the epsilon related  
drafts die a slow death and think it would be good if they would be  
published as informational. While writing this I realise I should  
probably bring this point to namedroppers.


--Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20050525/5481d729/attachment.html 

From pk at DENIC.DE  Wed May 25 07:17:34 2005
From: pk at DENIC.DE (Peter Koch)
Date: Wed, 25 May 2005 13:17:34 +0200
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10581443@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM> <list-10581443@EXECDSL.COM>
Message-ID: <20050525111734.GB16864@denics7.denic.de>

Olaf M. Kolkman wrote:

> As far as I understand the "epsilon" work seems to be heading to non- 
> deployment. I have not heard of anybody seriously planning on its  

it's probably a bit early to commit to "planning", but we are definitely
considering and evaluating, i.e. people are working on it.

> deployment. I think it would be a shame to let the epsilon related  
> drafts die a slow death and think it would be good if they would be  

So do I; and while I have some issue with NSEC3 (the "paradox" problem,
which marka addressed quite nicely in MPLS), that or something similar is our
long term favorite. However, there is no tangible estimate for NSEC3's
availability or deployment yet, so we are looking for short to mid term
solutions. Ignoring the zone walking problem is none of our options and
we do want to deploy DNSSEC.

-Peter


From ben at algroup.co.uk  Wed May 25 08:22:57 2005
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 25 May 2005 13:22:57 +0100
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <2B6319AF-971B-4A50-BDD1-349F97DFA1D7@ripe.net>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM> <2B6319AF-971B-4A50-BDD1-349F97DFA1D7@ripe.net>
Message-ID: <42946E21.4050409@algroup.co.uk>

Olaf M. Kolkman wrote:
> 
> On May 25, 2005, at 12:37 AM, Ben Laurie wrote:
> 
>>
>> It seems to me quite inappropriate to characterise the importance or
>>
>> relevance of an approach by the amount of list bandwidth it uses up. We
>>
>> believe in DNSSEC and NSEC3, we want it to happen, we don't want to
>>
>> waste your time on considering half-baked versions of it.
>>
>>
>>
> 
> For what its worth.
> 
> NSEC3 is on the groups agenda and I feel that after this update has been
> published we should make the jump from vapourware to software and
> organise a workshop to understand possible issues. In the past those
> workshops have shown to be more than worthwhile in getting good specs.
> Question: anybody doing an implementation, server/client side?

I have NSEC2 patches for BIND 9. It shouldn't be hard to update to NSEC3.

Cheers,

Ben.


From roy at dnss.ec  Wed May 25 08:27:56 2005
From: roy at dnss.ec (Roy Arends)
Date: Wed, 25 May 2005 14:27:56 +0200 (CEST)
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10582138@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
 <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com>
 <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM>
 <2B6319AF-971B-4A50-BDD1-349F97DFA1D7@ripe.net> <list-10582138@EXECDSL.COM>
Message-ID: <Pine.BSO.4.56.0505251425001.7361@trinitario.schlyter.se>

On Wed, 25 May 2005, Ben Laurie wrote:

> Olaf M. Kolkman wrote:
> >
> > On May 25, 2005, at 12:37 AM, Ben Laurie wrote:
> >
> >>
> >> It seems to me quite inappropriate to characterise the importance or
> >>
> >> relevance of an approach by the amount of list bandwidth it uses up. We
> >>
> >> believe in DNSSEC and NSEC3, we want it to happen, we don't want to
> >>
> >> waste your time on considering half-baked versions of it.
> >>
> >>
> >>
> >
> > For what its worth.
> >
> > NSEC3 is on the groups agenda and I feel that after this update has been
> > published we should make the jump from vapourware to software and
> > organise a workshop to understand possible issues. In the past those
> > workshops have shown to be more than worthwhile in getting good specs.
> > Question: anybody doing an implementation, server/client side?
>
> I have NSEC2 patches for BIND 9. It shouldn't be hard to update to NSEC3.

I'm busy with adding NSEC3 to Net::DNS, and with a zone signer in perl
independent of dnssec-signzone to keep the genpool diverse :)

Roy


From ben at algroup.co.uk  Wed May 25 08:38:09 2005
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 25 May 2005 13:38:09 +0100
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10581570@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM> <list-10581443@EXECDSL.COM> <list-10581570@EXECDSL.COM>
Message-ID: <429471B1.9080308@algroup.co.uk>

Peter Koch wrote:
> So do I; and while I have some issue with NSEC3 (the "paradox" problem,
> which marka addressed quite nicely in MPLS)

MPLS?


From pk at DENIC.DE  Wed May 25 08:46:06 2005
From: pk at DENIC.DE (Peter Koch)
Date: Wed, 25 May 2005 14:46:06 +0200
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10582283@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM> <list-10581443@EXECDSL.COM> <list-10581570@EXECDSL.COM> <list-10582283@EXECDSL.COM>
Message-ID: <20050525124606.GC16864@denics7.denic.de>

> > So do I; and while I have some issue with NSEC3 (the "paradox" problem,
> > which marka addressed quite nicely in MPLS)
> 
> MPLS?

sorry, no pun intended. I thought the meeting was in Minneapolis.

-Peter


From rlegene at gmail.com  Wed May 25 10:19:40 2005
From: rlegene at gmail.com (Robert Martin-Legene)
Date: Wed, 25 May 2005 16:19:40 +0200
Subject: [dnssec-deployment] NSEC3 progress (was: Re: [dnssec-deployment] meeting announcement: 25 May 2005)
In-Reply-To: <list-10573125@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
	 <list-10569089@EXECDSL.COM>
	 <20050524172437.GP17267@chinook.corpit.vrsn.com>
	 <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM>
	 <list-10573125@EXECDSL.COM>
Message-ID: <487354f105052507198ff6bd7@mail.gmail.com>

On 24/05/05, Roy Arends <roy at dnss.ec> wrote:
> On Tue, 24 May 2005, Sam Weiler wrote:
> > That says to me that people don't care very much.  Perhaps the
> > proponents of it have decided that the epsilon approach is sufficient,
> > or they simply don't want to do DNSSEC at all?

Please don't take this the wrong way. I think it's great that all
aspects of DNSSEC is being investigated, but I really wondered (and
wonder) why people were still working on epsilon when NSEC3 is coming
"soon". Of course this is all religious discussions, and I was just
wondering if people really want _epsilon_ (and not questioning about
NSEC3). I guess it really shows people's different PoV.

I think some of the reasons why there's no input is that people
appreciate the quality of the work that's been done, or they don't
have enough time to read all drafts from the ietf-groups they are
interested in, or they dont understand the document but still think
it's important. I am probably category 1 & 2 myself (and this lists
teleconf always surprises me in the middle of dinner).


From markk at verisignlabs.com  Wed May 25 10:26:24 2005
From: markk at verisignlabs.com (Mark Kosters)
Date: Wed, 25 May 2005 10:26:24 -0400
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10581443@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM> <list-10581443@EXECDSL.COM>
Message-ID: <20050525142624.GB3223@verisignlabs.com>

On Wed, May 25, 2005 at 01:01:12PM +0200, Olaf M. Kolkman wrote:
> NSEC3 is on the groups agenda and I feel that after this update has  
> been published we should make the jump from vapourware to software  
> and organise a workshop to understand possible issues. In the past  
> those workshops have shown to be more than worthwhile in getting good  
> specs. Question: anybody doing an implementation, server/client side?

We are planning to do an server side implementation of NSEC3 with
opt-in behavior for com and (hopefully) net this year.

Mark

-- 

Mark Kosters            markk at verisignlabs.com       Verisign Applied Research


From paul at vix.com  Wed May 25 10:37:31 2005
From: paul at vix.com (Paul Vixie)
Date: Wed, 25 May 2005 14:37:31 +0000
Subject: [dnssec-deployment] NSEC3 progress (was: Re: [dnssec-deployment] meeting announcement: 25 May 2 
In-Reply-To: Your message of "Wed, 25 May 2005 16:19:40 +0200."
             <list-10583597@EXECDSL.COM> 
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573125@EXECDSL.COM>  <list-10583597@EXECDSL.COM> 
Message-ID: <20050525143731.3A36114D64@sa.vix.com>

> ... but I really wondered (and wonder) why people were still working
> on epsilon when NSEC3 is coming "soon".

because epsilon doesn't require any change of behaviour in the clients,
it is perceived as "easier to deploy" than NSEC3.


From weiler+lists.dnssec-deploy at watson.org  Wed May 25 10:53:46 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Wed, 25 May 2005 07:53:46 -0700 (PDT)
Subject: [dnssec-deployment] NSEC3 progress (was: Re: [dnssec-deployment]
 meeting announcement: 25 May 2
In-Reply-To: <list-10583597@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> 
 <list-10569089@EXECDSL.COM>  <20050524172437.GP17267@chinook.corpit.vrsn.com>
  <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> 
 <list-10573125@EXECDSL.COM> <list-10583597@EXECDSL.COM>
Message-ID: <20050525073959.M76664@fledge.watson.org>

> ... I really wondered (and wonder) why people were still working on 
> epsilon when NSEC3 is coming "soon".

What Paul said, and...

Because we're pessimistic about what "soon" will be.

DS was expected to be a small change, too.  It took only ten months 
between the first DS draft (31 May 2001) and the WGLC (28 March 2002), 
after which we found three showstopper protocol bugs.

It actually took 2.5 years to get RFC3658 (18 Dec 2003) and another 
five months to get RFC3755, which fixed the last of those three bugs 
(27 May 2004), a total a three years (for the specs, though not 
necessarily the code).

I see NSEC3 as being a change similar in magnitude to DS.  Hopefully 
I'm wrong.

-- Sam


From ben at algroup.co.uk  Wed May 25 11:21:36 2005
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 25 May 2005 16:21:36 +0100
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10582349@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM> <list-10569089@EXECDSL.COM> <20050524172437.GP17267@chinook.corpit.vrsn.com> <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM> <list-10573695@EXECDSL.COM> <list-10581443@EXECDSL.COM> <list-10581570@EXECDSL.COM> <list-10582283@EXECDSL.COM> <list-10582349@EXECDSL.COM>
Message-ID: <42949800.3020100@algroup.co.uk>

Peter Koch wrote:
>>>So do I; and while I have some issue with NSEC3 (the "paradox" problem,
>>>which marka addressed quite nicely in MPLS)
>>
>>MPLS?
> 
> 
> sorry, no pun intended. I thought the meeting was in Minneapolis.

Ah. I was totally confused my MultiProtocol Label Switching.

So, remind me, which of the various alleged paradoxes did you have in mind?

Cheers,

Ben.


From mankin at psg.com  Wed May 25 13:54:46 2005
From: mankin at psg.com (Allison Mankin)
Date: Wed, 25 May 2005 10:54:46 -0700
Subject: [dnssec-deployment] NSEC3 progress 
In-Reply-To: Message from "Olaf M. Kolkman" <olaf@ripe.net> 
   of "Wed, 25 May 2005 07:01:22 EDT." <redirect-10581449@EXECDSL.COM> 
Message-ID: <auto-000010586102@EXECDSL.COM>

Hi, Olaf,

> and organise a workshop to understand possible issues. In the past  
> those workshops have shown to be more than worthwhile in getting good  
> specs. Question: anybody doing an implementation, server/client side?

> As far as I understand the "epsilon" work seems to be heading to non- 
> deployment. I have not heard of anybody seriously planning on its  
> deployment. 

It surely is hard to deploy what's not implemented :)  So I guess
you are also saying you have not heard of any implementation? 
(Which is what's been said in the teleconfs in passing a couple of times...)
I would like to explicitly query on this, and add something to your
query above.  I think that workshop you propose on NSEC3 should be
like a forcing function:  it should try to bring both server and
client implementations to good states at an early date.

> I think it would be a shame to let the epsilon related  
> drafts die a slow death and think it would be good if they would be  
> published as informational. While writing this I realise I should  
> probably bring this point to namedroppers.

I agree, not at all a topic for this list.

Allison


From rlegene at gmail.com  Wed May 25 16:01:09 2005
From: rlegene at gmail.com (Robert Martin-Legene)
Date: Wed, 25 May 2005 22:01:09 +0200
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10583676@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>
	 <list-10569089@EXECDSL.COM>
	 <20050524172437.GP17267@chinook.corpit.vrsn.com>
	 <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM>
	 <list-10573695@EXECDSL.COM> <list-10581443@EXECDSL.COM>
	 <list-10583676@EXECDSL.COM>
Message-ID: <487354f1050525130161c5bc3e@mail.gmail.com>

On 25/05/05, Mark Kosters <markk at verisignlabs.com> wrote:
> We are planning to do an server side implementation of NSEC3 with
> opt-in behavior for com and (hopefully) net this year.

Hi Mark.

This is good to hear.

Can you explain exactly what "server side" covers in this sentence?
I'm just curious since it could mean a lot of different subsets of
servers.

-- Robert, .dk


From davidb at verisignlabs.com  Wed May 25 16:18:42 2005
From: davidb at verisignlabs.com (David Blacka)
Date: Wed, 25 May 2005 16:18:42 -0400
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10587932@EXECDSL.COM>
References: <list-10557307@EXECDSL.COM> <list-10568529@EXECDSL.COM>	 <list-10569089@EXECDSL.COM>	 <20050524172437.GP17267@chinook.corpit.vrsn.com>	 <42937DE4.9000406@shinkuro.com> <list-10571752@EXECDSL.COM>	 <list-10573695@EXECDSL.COM> <list-10581443@EXECDSL.COM>	 <list-10583676@EXECDSL.COM> <list-10587932@EXECDSL.COM>
Message-ID: <4294DDA2.80103@verisignlabs.com>

Robert Martin-Legene wrote:
> On 25/05/05, Mark Kosters <markk at verisignlabs.com> wrote:
> 
>>We are planning to do an server side implementation of NSEC3 with
>>opt-in behavior for com and (hopefully) net this year.
> 
> 
> Hi Mark.
> 
> This is good to hear.
> 
> Can you explain exactly what "server side" covers in this sentence?
> I'm just curious since it could mean a lot of different subsets of
> servers.

Server side means that we will have a pilot that will serve versions of 
com/net that are signed using NSEC3.  It will be our own platform (i.e., 
not BIND, not nsd).

Basically, we are planning on updating our old opt-in pilot to use NSEC3.

-- 
David Blacka    <davidb at verisignlabs.com>
Sr. Engineer    VeriSign Applied Research


From olaf at ripe.net  Fri May 27 05:21:56 2005
From: olaf at ripe.net (Olaf M. Kolkman)
Date: Fri, 27 May 2005 11:21:56 +0200
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10586103@EXECDSL.COM>
References: <redirect-10581449@EXECDSL.COM>
	<list-10586103@EXECDSL.COM>
Message-ID: <20050527112156.31ae01e5.olaf@ripe.net>

On Wed, 25 May 2005 10:54:46 -0700
Allison Mankin <mankin at psg.com> wrote:

> Hi, Olaf,
> 
> > and organise a workshop to understand possible issues. In the past  
> > those workshops have shown to be more than worthwhile in getting good  
> > specs. Question: anybody doing an implementation, server/client side?
> 
> > As far as I understand the "epsilon" work seems to be heading to non- 
> > deployment. I have not heard of anybody seriously planning on its  
> > deployment. 
> 
> It surely is hard to deploy what's not implemented :)  So I guess
> you are also saying you have not heard of any implementation? 

I have made a "proof of concept" in perl. But that implementation is
really not more than a crude hack and would not scale to any serious
production. Registries seriously considering deployment should write
their own code and I am not sure of any of that work has been done. 



> (Which is what's been said in the teleconfs in passing a couple of times...)
> I would like to explicitly query on this, and add something to your
> query above.  I think that workshop you propose on NSEC3 should be
> like a forcing function:  it should try to bring both server and
> client implementations to good states at an early date.


My gut feeling is that such a workshop could be done in Europe, since
most of the stake holders are located there. That such workhsop does
not necessarily need to piggy back on a RIPE meeting or a IETF meeting
and that September/October seems a nice target. 



-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org


From ben at algroup.co.uk  Mon May 30 10:10:31 2005
From: ben at algroup.co.uk (Ben Laurie)
Date: Mon, 30 May 2005 15:10:31 +0100
Subject: [dnssec-deployment] NSEC3 progress
In-Reply-To: <list-10615494@EXECDSL.COM>
References: <redirect-10581449@EXECDSL.COM>	<list-10586103@EXECDSL.COM> <list-10615494@EXECDSL.COM>
Message-ID: <429B1ED7.2030803@algroup.co.uk>

Olaf M. Kolkman wrote:
> On Wed, 25 May 2005 10:54:46 -0700
> Allison Mankin <mankin at psg.com> wrote:
> 
> 
>>Hi, Olaf,
>>
>>
>>>and organise a workshop to understand possible issues. In the past  
>>>those workshops have shown to be more than worthwhile in getting good  
>>>specs. Question: anybody doing an implementation, server/client side?
>>
>>>As far as I understand the "epsilon" work seems to be heading to non- 
>>>deployment. I have not heard of anybody seriously planning on its  
>>>deployment. 
>>
>>It surely is hard to deploy what's not implemented :)  So I guess
>>you are also saying you have not heard of any implementation? 
> 
> 
> I have made a "proof of concept" in perl. But that implementation is
> really not more than a crude hack and would not scale to any serious
> production. Registries seriously considering deployment should write
> their own code and I am not sure of any of that work has been done. 

I have a BIND implementation of NSEC2. Since we mostly know what NSEC3
looks like, I can upgrade that implementation, which I will be doing in
the near future.

Cheers,

Ben.


From galvin at elistx.com  Mon May 30 15:08:39 2005
From: galvin at elistx.com (James M Galvin)
Date: Mon, 30 May 2005 15:08:39 -0400
Subject: meeting announcement: 1 June 2005
Message-ID: <1738E0CCE17B6D09B96C74EC@[10.0.0.4]>

This meeting will be held at the usual time of:

    1200 Los Angeles, San Francisco
    1200 Phoenix
    1500 Washington
    1900 UTC
    2100 Netherlands
    2200 Israel
    0400 Tokyo (the next day)
    0500 Melbourne (the next day)

The usual teleconference logistics are as follows.  These do not change.
You will hear music until the moderator joins (that would be me).

    USA Toll Free Number: +1 888-221-7341
    USA Toll Number:      +1 973-935-2305

    Passcode: 599786
    Leader:   James Galvin
	      employed by ICANN if speaking to an operator

    Jabber:   dnssec-deployment at conference.jabber.org
	      This is a public room.

    If your phone does not have a mute capability you can use "*6" to
    mute and unmute your connection.

    DIAL OUT:
        1. ISC SIP Bridge - contact me for SIP identifiers


DRAFT AGENDA

 -- Short Reports (10 minutes)

    * Fall technical/interop meeting - Allison Mankin

    * DNSSEC performance - Can NIST take the lead?


 -- Secure Entry Point (SEP) management

    This relates to three of our document deployment issues:

     2. Timing of signing the root zone and/or management of islands of
        trust
     3. Root key rollover and distribution
     4. Trust anchor key rollover and distribution

    Both Paul Vixie and Sam Weiler distributed documents and pointers to
    other references on the mailing list.  Everyone is asked to review
    these documents in preparation for a detailed discussion.

    There has been a good discussion on our mailing list, as well as
    others (notably namedroppers).

    Although this issue has been discussed quite a bit in other fora, no
    resolution has been forthcoming.  This issue affects deployment and
    thus it is within our charter to press for a resolution, either
    within this group or wherever it is most appropriate.



From galvin at elistx.com  Mon May 30 15:06:44 2005
From: galvin at elistx.com (James M Galvin)
Date: Mon, 30 May 2005 15:06:44 -0400
Subject: meeting summary: 25 May 2005
Message-ID: <58C550F412449BAABB55ABAC@[10.0.0.4]>

DNSSEC Deployment Working Group
25 May 2005


PRESENT:
    Steve Crocker
    Jim Galvin

    Allison Mankin
    Amy Friedlander
    David Blacka
    Ed Lewis
    Geoff Sisson
    Jaap Akkerhuis
    Jakob Schlyter
    Mark Kosters
    Mike St. Johns
    Peter Koch
    Ralph Droms
    Rodney Joffe
    Russ Mundy
    Sam Weiler
    Scott Rose

    jbr - does anybody know who this is?  this person did not respond to
    multiple requests for an identity.


REGRETS:
   Johan Ihren
   Olaf Kolkman
   Steven Cheung


SUMMARY


 - When can we have a technical workshop?

   During our last meeting we deferred most of the discussion of what to
   cover and when to hold a technical or interoperability workshop.  It
   was briefly noted that the RIPE Amsterdam meeting had the advantage
   of giving developers more time to prepare as compared to the IETF
   Paris meeting.  The suggested topic to cover in the workshop is the
   interoperability of epsilon implementations.

There is a question as to whether or not there will be implementations
of epsilon or NSEC3.

Ralph Droms indicated that Cisco will be implementing DNSSEC but he did
not expect to have anything in time for October.

Mark Kosters indicated that Verisign will be doing an NSEC3
implementation with OPT-IN (i.e., NSEC chain skips over unsigned
delegation).  They expect to be showcasing a server implementation in
the fourth quarter but October is likely to be too early.

Geoff Sisson noted that Ben Laurie had done an NSEC2 implementation.

Mike St. Johns indicated that Nominum will have DNSSEC ready by October,
subject to customer demand, but NSEC3 was not even on the table yet.

Allison Mankin summarized that it looks like there will be enough to do
something in October, perhaps even some early work in August at the
IETF.  She proposed a planning meeting at the IETF-Paris for a multi-day
event in October at the RIPE-Amsterdam.


 - Managing secure entry points and transitioning to a signed parent

   In an ideal deployment there would be a very low barrier to entry, an
   enterprise could sign its zone and get immediate external benefit
   from having done so, a parent (e.g., a TLD) would sign its zone
   shortly thereafter, and the transition to inclusion in the larger
   infrastructure would be straightforward if not transparent.

   A concern is the tension between an orderly, top-down deployment:

       sign the root
       sign the TLDs
       sign the second level zones
       etc.

   And a bottoms-up, islands of trust deployment:

       enterprises sign their zones
       enterprises "distribute" their public key
       when the parent is ready the public key is "moved up"
       etc.

   The tension arises from wondering if the trust models will converge
   into a single, trusted infrastructure, i.e., if second-level zones
   can proceed without their TLDs, will there be sufficient motivation
   for the TLDs to sign their zones?

   This concern is related to three of the 11 issues listed in the
   DNSSEC Deployment Roadmap:


     2. Timing of signing the root zone and/or management of islands of
        trust

     A DNSSEC signed zone operating without a signed delegation from
     their parent zone is commonly called an 'island of trust'; this
     issue deals with questions that arise when zones are signed but the
     root is not.

     This issue addresses non-root trust anchors.  At last reporting (16
     February 2005) there was a DNSOP document in last call that spoke
     to this issue.


     3. Root key rollover and distribution

     Procedures for initial distribution of the root public key,
     periodic rollover of the public key, and its distribution

     This issue addresses root trust anchors.  It is largely similar to
     Issue 2 but because it is the root you probably want a separate
     document so you can say more about security.  And, unfortunately,
     there are political issues.  The root is just another trust anchor
     but it is a "special" one.  Changing the root key will have an
     impact just in pure numbers, as compared to any other trust anchor.


     4. Trust anchor key rollover and distribution

     Procedures for initial distribution of the trust anchor public key,
     periodic rollover of the public key, and its distribution; needed
     in Isolated, Sparse or Dense deployment, or for some applications.

     This issue addresses trust anchors in general.  There are some
     issues that go with a secure apex based on a spectrum of how much
     you care.

Steve Crocker quickly summarized the "bidding" by noting

* DLV by Paul Vixie
* Alternative DLV by Sam Weiler
* Implementation of a third option by Andrews

These three may not be in sync.

Sam Weiler pointed out that there have been many lengthy discussions
about different ways to do this.

Steve stated that the concern, irrespective of the mechanism chosen, is
that we need a means to manage trust anchors when the TLDs are not ready
to go.  Russ Mundy generalized that to any parent not being ready as
opposed to just TLDs.

Jim Galvin asked if managing the trust anchors was separate from
incorporating existing public keys in islands of trust into the larger
island of the parent?  Steve agreed that point need to be covered also,
with Russ suggesting the incorporation is easy compared to managing the
trust anchors.

Steve asked for references to discussion, resolution, and testing
documentation.  Although there has been plenty of discussion, no agreed
resolution is apparent.


Mark Kosters expressed concern that any mechanism put in place that
reduces the motivation or dependency on a parent will likely stay in
place forever and delay ubiquitous deployment.

Steve suggested that a significant concern is that we have this great
technology but we fail.  The failure mode Mark is suggesting is somewhat
intermediate between that and full deployment:

    limited deployment, i.e., will not be universal

    provide this mechanism and you prevent broad deployment

Mark was also concerned that DLV introduces a single point of failure,
i.e., you have to reference things in the DLV zone.  Mike St. Johns
asserted that it exacerbates the problem of provable non-existence.
Mark added that it becomes a traffic sink.

The discussion closed noting that we need other folks to be actively
involved in this discussion, including Paul Vixie, Matt Larson, and
Johan Ihren.

Everyone is asked to review the relevant documents and we will pick up
this discussion next week.



 -- Regarding Issue 8 from the DNSSEC Deployment Roadmap:

      8. Computational and communication resources required

      Considers operational requirements for additional storage, CPU
      time and communication bandwidth and evaluates the affect these
      additional requirements may have on adoption and use.

    If available, Olafur and Jaap will present their material.

    * Olafur Gudmundsson

      Olafur Gudmundsson volunteered to create and maintain a list of
      metrics people should collect and use for reporting.  He noted
      that we needed metrics for both resolvers and servers.

    * Jaap Akkerhuis

      Jaap Akkerhuis noted that NL Netlabs had a simulation of CPU and
      storage requirements for DNSSEC.  Jaap agreed to get some material
      on the NL Netlabs activities for review.


Jaap Akkerhuis reported that NL NetLabs is discussing redoing their
previous work.  It is not yet committed or guaranteed.

Russ Mundy noted the paper put forth on the mailing list by Bill
Manning, for which Sam Weiler posted a detailed summary.  The short
summary is that the conclusions are inconclusive because there seem to
be factors that are not addressed.



From jaap at NLnetLabs.nl  Tue May 31 04:24:46 2005
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Tue, 31 May 2005 10:24:46 +0200
Subject: [dnssec-deployment] meeting announcement: 1 June 2005 
In-Reply-To: Your message of Mon, 30 May 2005 15:08:39 -0400.
             <list-10672263@EXECDSL.COM> 
Message-ID: <200505310824.j4V8Okuf022795@bartok.nlnetlabs.nl>


    This meeting will be held at the usual time of:
    ... etc

Regrets, I cannot make it this time. To add this point:

	Jaap Akkerhuis reported that NL NetLabs is discussing redoing
	their previous work.  It is not yet committed or guaranteed.

Note that I did send the information about the previous work to the
list. (For the message see the archive; to be exact:
http://mail.shinkuro.com:8100/Lists/dnssec-deployment/Message/4.html)

	jaap


From jaap at NLnetLabs.nl  Tue May 31 07:20:01 2005
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Tue, 31 May 2005 13:20:01 +0200
Subject: Selling dnssec ...
Message-ID: <200505311120.j4VBK1mt046913@bartok.nlnetlabs.nl>

It might be a far stretch, but maybe the ISSE conference
(http://www.eema.org/static/isse/) is an opportunity you talk about
dnssec deployment.

	jaap


From paul at vix.com  Tue May 31 10:04:55 2005
From: paul at vix.com (Paul Vixie)
Date: Tue, 31 May 2005 14:04:55 +0000
Subject: [dnssec-deployment] Selling dnssec ... 
In-Reply-To: Your message of "Tue, 31 May 2005 13:20:01 +0200."
             <list-10680970@EXECDSL.COM> 
References: <list-10680970@EXECDSL.COM> 
Message-ID: <20050531140455.ADFC714D5C@sa.vix.com>

> It might be a far stretch, but maybe the ISSE conference
> (http://www.eema.org/static/isse/) is an opportunity you talk about
> dnssec deployment.

after seeing the CFP at <http://www.eema.org/static/isse/call.htm>, i agree.


From weiler+lists.dnssec-deploy at watson.org  Tue May 31 15:54:03 2005
From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler)
Date: Tue, 31 May 2005 12:54:03 -0700 (PDT)
Subject: Regrets, Re: [dnssec-deployment] meeting announcement: 1 June 2005
In-Reply-To: <list-10672263@EXECDSL.COM>
References: <list-10672263@EXECDSL.COM>
Message-ID: <20050531125209.R28007@fledge.watson.org>

I'm scheduled to be on an airplane 2:35-4:12pm tomorrow, which 
presumably means I won't be joining you.  Maybe next time.

-- Sam