DNS Workshop
ICANN - SYDNEY
24 June 2009

>>STEVE CROCKER:   Well, this is going to be a bit of a personal
challenge to remain poised in the glitches here.  I'm Steve Crocker, to
my right is Russ Mundy, cochair of the DNSSEC deployment working group.
We have a very packed agenda.  We have a quite exciting and dense set
of preferences related to DNSSEC, quite a few interesting things are
going on.  What should be on the screen is the agenda and as I say
we're having a little trouble assembling the pieces so rather than
wasting more time fiddling with all of this, let me take you through it
verbally and do it incrementally and we'll just take this on the fly. 
All of the presentations and even the agenda will be on the Web site
eventually.  

We're going to start out with some presentations related to signing
the root starting with Ashley Heineman from the U.S. Department of
Commerce, NTIA. 

And then I believe we're having Joe Abley from ICANN with a related
presentation, and then Suzanne Woolf reporting on a symposium related
to the effects of deploying a signed root from a symposium that was
held a couple of weeks ago.

We'll, then, move into a -- a quite substantive set of presentations
about implementations, activities around the world with quite a lot of
emphasis on this region.  And then we'll close up with a couple of
other presentations and I'll take you through all that.  Would you like
to say a word or two, Russ?

>>ROSS MUNDY:   Just a quick hello, and welcome, everyone.  This is a
very full session, as Steve said, and it looks like we have a very full
room.  Believe it or not we do have a chair at the front of the room if
anyone else wants to join us up here but we'll try to move along and
keep right on schedule.

>>STEVE CROCKER:   With that, Ashley, can I turn this over you and
I'll flip slides for you on your queue.

>>ASHLEY HEINEMAN:   Good morning, everyone, the purpose of this
presentation is to give you an overview and status update in terms of
where things are with implementing DNSSEC at the root.  ICANN and the
Department of Commerce issued their individual press releases earlier
this month indicating our intent to cooperate in implementing DNSSEC at
the root with a goal of an operational signed root by the end of the
year.  So the purpose of this presentation is to give you some
background in terms of how we came to that decision, what we plan to
have at least as the interim approach to implementing at the root, as
well and some potential next steps to moving forward.  Next slide.

So just by way of background, as I'm sure many of you are aware, NTIA
issued a notice of inquiry in October of last year on the subject of
implementing DNSSEC at the root.  That included a lot of questions as
to whether or not it should be implemented as well as some proposed
methods for implementing.  As a part of that process, we received 55
comments from industry nonprofit organizations, academia, and
individuals, all of these comments as well as the NOI itself are still
posted on our Web site at this URL, if you're interested in reading
them in more detail.  Next slide.

So coming out of this process, first and foremost, what was very clear
is that there is indeed a lot of support for implementing DNSSEC at the
root.  Other important points that came out of this process were that
implementation should take place as soon as practically possible.  It
should be done in a manner that maintains a security instability of the
overall DNS.  At least from the TLD perspective and the operations they
have on a regular basis for making other changes to the root, there was
an indication that a DNSSEC process should be, to a certain extent,
aligned with whatever the root's own management process is at that
time, and also many took the opportunity to remind commerce what DNSSEC
is all about.  That it is not about control, that it is about data
integrity and authenticity.  Next slide, please.

Moving forward, what we took out of this NOI process as well as a
number of conversations that we had with experts participating in other
events organized on this subject as well as talking to some of those
who have already implemented DNSSEC in their zones was that, yes, the
time is ripe.  It is important to move forward with implementing DNSSEC
at the root.  At commerce, we determined a goal for ourselves.  A goal
being having an operationally signed root by the end of this year, just
to reiterate, this is a goal.  If, during the process of testing,
something occurs that we don't feel we are at that time in a good
position to flip the switch, we will certainly take that into account. 
The purpose here isn't to rush into any kind of an implementation
process unless things are pretty firm and people are confident with how
things are moving forward.  So in order to keep in line with the
results of the NOI, recognizing that in order to achieve this goal,
things will have to move forward pretty aggressively but still wanting
to do things in a manner that maintains the security and stability of
the DNS.  We determined that for the interim, the approach that we will
take in implementing, is to closely align a DNSSEC process on top of
the current root zone management process.  Once implemented and once
operational for a time yet to be determined, we will initiate a review
process.  The point of this review process will be to take into
consideration any advancement in technology, process or procedure
related to the DNSSEC.  And then once we've taken these points into
consideration, then determine whether or not modifications need to take
place and what kinds of modifications to make sure that things are
streamlined, we're up to date with where things are going, learning
from experiences such as Sweden and Brazil and others who have already
implemented DNSSEC and the direction they are going in that respect. 
And just to reiterate, we see this as an iterative process.  We don't
see this -- we see this as evolving over time as DNSSEC evolves.  I
think we're still somewhat in the early stages in terms of DNSSEC being
operational.  And throughout this process, not just in the testing and
implementation, but throughout perhaps a lifetime of DNSSEC at the root
to be in constant consultation with the technical community and other
interested stakeholders in this process.  Next slide.

So as I mentioned in the previous slide, the intent here is to align
as close as possible DNSSEC processes and procedures with the current
root zone management process.  As I'm sure almost everyone here in the
room knows, the current root zone management process includes three
parties, that being ICANN and the IANA functions operator, NTIA as the
administrator, and VeriSign as a root zone maintainer.  We set up a
basic architecture at the highest level to align things with the
process.  So ICANN, as the IANA functions operator, they will be
responsible for the root KSK management process.  ICANN will also be
responsible for the publication/distribution of the root key.  You see
this as perhaps the most important function here.  I think there's a
very important role here that ICANN has to play in working with the
community and determining what is the best mechanism for doing this and
how is that mechanism going to evolve over time.  And very closely in
line to what ICANN already does today in the root zone process, which
is requesting changes from TLD operators for making changes to the root
zone is also accepting the public key information from the TLD
operators.  Next slide.

So on the root zone maintainer side, which is VeriSign, their
responsibilities, in addition to what they do today which is generating
the root zone file and distributing that file, in between those two
processes they will now be responsible for signing the root.  Realizing
that the root zone file is generated and distributed twice a day, it
made operational sense, at least from our perspective, that for the
interim VeriSign have easy access to the ZSK so therefore, they will
have the responsibility of managing this -- the root ZSK process.  Next
slide.

And just as a visual, just wanted to give a quick overview with this
diagram what the current root zone management process is.  The TLD
operator puts forward the change request to IANA who, then, processes
that change request, the information is pushed to NTIA as the
administrator who verifies that a process and procedure was followed
correctly.  Then VeriSign is authorized to make that change to the root
zone file which is generated and then distributed to the root server
operators.  Next slide.

And this diagram is just to show how we intend DNSSEC to be overlaid
on to this process.  So where the TLD operator submits change requests
to date this will also be a mechanism where they can include their
public key information and update that information.  It will go through
a similar processing process.  NTIA will verify that that process was
followed and authorize VeriSign to include this information to the root
zone file.  The new step in this particular process is that at this
point VeriSign the sign the zone, prior to distribution, then go out to
the root server operators.  In terms of the key management, you see a
freestanding box at this moment.  As I said earlier, it has been
determined that ICANN will be responsible for this management process. 
Details have not been established to date.  I think they're in the
works right now, as I've been told, basically ICANN working with
VeriSign will be developing detailed plans and procedures for how this
process will take place.  But just for the sake of illustration, keys
will be -- the KSK will be generated, the root key set will be signed. 
If you see VeriSign is shown as generating the ZSK they will push their
public portion of the key over to -- to be signed, the signature will
go back, then utilized for signing the zone.  The public portion of the
root KSK will then be the responsibility of ICANN to publish for the
community.  So this should cover at least the basics in terms of how,
for the interim, this process will be conducted.  Next slide, please.

So as I mentioned, ICANN and VeriSign, we're going to rely solely,
well, not solely but primarily and largely on them for the development
of the details of the plans.  What NTIA did, in close cooperation with
our sister agency, the national institute of standards and technology,
is develop an overarching set of technical requirements that include
things like minimal levels of security, requirements to have detailed
plans and procedures in place for key rollover for auditing, those
sorts of things.  This document is pretty much finalized and I hope to
have available published in some -- some manner, but the point here is
that we're going to be actively seeking input from the technical
community on this document to make sure that we have everything
covered.  Simultaneously, ICANN and VeriSign are, again, working to
draft testing and implementation plans.  Our hope is that an initial
set of draft plans will be available prior to the IETF meeting in
Stockholm where we can start initiating consultation with the community
and by the time, hopefully in the very near future, we will have at
least a good start at testing and implementation plans that -- with the
-- the level of confidence in those plans and we can, then, start
testing -- a testing initiation process.  Which what we're trying to
shoot for is late summer, early fall, if necessary.  And then at that
point, once testing commences, we can determine how -- how further --
how much further this testing needs to go and how close we really are
going to be in terms of achieving the end of the year goal.  So this is
a very broad overview of how we see things moving forward and that is
all for my presentation.  And I also want to say, if Joe Abley is here,
if there's anything you wanted to elaborate on.

>>STEVE CROCKER:   So my understanding is that Joe actually has some
slides of his own to present at the moment, is that right?

>>JOE ABLEY:   There you go.  Thanks, Steve, Ashley.  I have some
slides to present on some other DNSSEC projects at ICANN involving in
signing other zones that are not the root.  That's the next set. 
Sorry, I gave them to you late so you probably didn't get them ahead of
time.  Sorry about that.  Actually, I think that covered it at a high-
level.  I'd be happy to answer questions from the ICANN perspective.

>>STEVE CROCKER:   I think it would be appropriate to take questions,
so Bill, you want to chime in there?

>>BILL MANNING:  Sure.  If you back up a slide --  no.  Okay, so don't
back up a slide.  The schedule looks relatively aggressive with the --
with Joe being tasked with moving forward at a rapid rate of speed and
advice from the technical community lagging, if the technical community
comes up with something they don't like, Joe may be three or four steps
down the path already, and is there a way to inculcate comments from
the technical community after the fact.

>>STEVE CROCKER:   And who are you asking?

>>BILL MANNING:   You.

>>STEVE CROCKER:   Me, you've got the microphone.

>> We know how to pass the question.

>>BILL MANNING:   I would like Joe to answer that question.

>>JOE ABLEY:   That answers that, then.  So ICANN and elevator are I
sign on a technical engineering level have already started
collaborations, we had meetings last week trying to work out at a
technical level how this could be put together.  As Ashley said with
the goal of making a proposal that can be circulated before the ATF
which is the end of July.  Much of the infrastructure that we're
putting in place for this is fairly generic and can be used in many
different ways.  We're looking for a simple robust solution.  I don't
anticipate that we would invest a tremendous amount of engineering
effort in a plan ahead of time that would be subsequently subject to
substantial change by the community, because, to be honest, the
infrastructure is not that important.  The important thing is to make
sure that everybody's comfortable with the transparency and the
security of the solution and its stability.  So I think it's a
reasonable concern to have.  I think, in practical terms, if we
continue with our rapid progress towards getting proposals in front of
the community I don't expect any backtracking will, in practical, be
necessary.

>>BILL MANNING:   Trust us.  We're from ICANN.  We're here to help.

>>STEVE CROCKER:   Any other questions?  We have this funny, L-shaped
room.  And so I want to particularly invite people that I can't see
around this big post to stand up or wave your hand or something so that
we don't lose you, but I -- I don't want to give preferential treatment
only to the people seated around the table there.  That said, Roy, you
had your hand up.

>>ROY ARENDS:   Thank you, and Roy Arends.  The notice of inquiry
contained six proposals.  I read the responses, the 55 responses to
have a very clear drive to what's proposal number four.  And proposal
number four, just to enlighten you, proposal number four was the
solution where all the cryptographic procedures were concentrated in
one environment.  And the root zone maintainer would then become the
root zone distributor.  Obviously, that solution hasn't been chosen and
I'm curious what happened because this, to me, seems like a shotgun
wedding.

>>ASHLEY HEINEMAN:   As the person who had to go through all these
comments in excruciating detail I have to say that the conclusion that
we came from is that there was, in fact, no agreed-upon approach to how
it should be implemented.  In fact, there was quite a bit of support
for the M of N approach.  There were quite a number of commenters who
did not make any kind of hint as to how it should be done.  So I would
have to disagree to a certain extent that there was an overwhelming
support for any particular model.

>>ROY ARENDS:   Thank you, Ashley.  And I have another question and
you used the words "interim," and "iterative."  Am I correct that with
using those words you actually -- sorry.  After a certain number of
iterations, would we still have the same for instance the same actors
but a different process but can iterations also mean we would have
different actors?  Thank you.

>>ASHLEY HEINEMAN:   We have no preconceived notions on that point.  I
think if it makes sense to have additional actors involved, fine.  At
this point there was quite a few comments that said do not introduce
additional actors.  I think at least in our mind at this time, again,
not having any preconceived notions is that the functions can move
around from the existing actors and I think if there's enough community
support for introducing new actors that's also a possibility.

>>ROY ARENDS:   And thank you, Ashley and if I may, one final
question?  Thank you.  I'm not really sure to whom I should ask this
question, either Joe or Ken, if Ken is here, or Ashley.  The date set,
the end of this year, basically, and roots will be signed, does that
include publication in the root zone of TLD ZSKs -- sorry, the DNS
records of top-level domains, or is that a second process after the
fact and just signing the root in December, for instance, is just that,
signing the root no key chains from that?  Thank you.

>>ASHLEY HEINEMAN:   I'll take this first, Joe, and then if you want
to take it you're free to.  At this point we don't know.  I think we're
looking at all kinds of operations, whether it's a phased, a phased
approach or just going completely live and operational at the end of
the year, if we're ready at that point.  I think that's really going to
depend on what we get from ICANN and VeriSign as well as what input we
get from the community.

>>ROY ARENDS:   Thank you.

>>STEVE CROCKER:   Let me jump in on that last point a bit, Roy, and
it's a very good question.

Just for the benefit of everybody else, the point that you are
focusing on is that you can subdivide the so-called "signing the root"
into several different subpieces.  One of which is the generation in
use of the KSK and the ZSK just creating those and having those at the
top level.  And then as a separate matter, there's the acquisition of
keying material from the top-level domain operators and putting those
into the root zone and having those DS records signed by the -- with
the ZSK.  Those are the component parts of that.

It's worth noting that the acquisition of that keying material has
already been accomplished by ICANN, by IANA and publishing it through a
side mechanism called the interim trust anchor repository.  So there is
the -- that side of it, sort of the registrar function, if you will,
has been completed, it's been in operation for a while.  So that
narrows the question that you're focused on to moving that information
that already has been acquired and is visible at ICANN into the root
zone and that presumably is not very complicated but the place where
one might want to be careful is in the testing process and shaking down
all of the procedures and so forth and so it might still be worth
dividing all that.  I'm just trying to be explanatory here, not -- not
making a value judgment or making a estimate of what the timing is but
just trying to help clarify the question that you asked.  But to go one
step further, I guess there isn't any expectation to stop short of
putting all of the information in there, it's just a question of
getting it all done and by what time, is that fair?  That's -- that's
to either of you.

>>JOE ABLEY:  I'll use this one.

 >>BILL MANNING:  While Joe gets the other microphone, I will ask the
question -- and I apologize for those that have heard this before --
signing the root zone and releasing the keys so people can start
validating are two different activities.  There has been -- at the
NANOG meeting last week, there was a presentation by Suzanne that
talked about -- oh, there it is right there.  That talked about some of
the possible issues downstream which have yet to have sufficient study.
And so it would be potentially reasonable to sign the root zone and not
release the keys as a first -- as a step.

 >>STEVE CROCKER:   Bill, as a technical matter, once the root is
signed, the key is actually in the root zone.  Yes?

 >>JOE ABLEY:   Joe Abley here.  I think it's possible to imagine a
staged deployment, particularly if we're nervous and want to test
extensively where we could actually sign records in the root zone but
not publish the DNSkeys.  This seems technically feasible.  Whether or
not it's operationally feasible with deployed implementation of
validators is another matter.  But it's certainly an avenue that we
could investigate as a means of trying in such a way that we could
unsign it if there was a problem.

 >>RUSS MUNDY:   This is Russ. Let me jump in and say, hopefully,
these are the types of details or some of these types of things, the
details that will be contained in the implementation plan that Ashley
had talked about earlier being released before the IETF.

 >>JOE ABLEY:   Right.  I think we're all committed to try and put as
many proposals on the table as we can before Stockholm so we can get as
early and as complete a consultation from the technical community as we
can.  That, hopefully, will also include by then a testing plan which
quite possibly is the plan that requires the most input and affects the
most set of people.  I had one other point on Roy's comment earlier as
to how early DNS records for TLDs might be inserted in the root zone. 
While it's true that we've collected trust anchors in the ITAR today --
and Barbara might be able to say more about this from a process point
of view.  But I would imagine that DS records for individual TLDs would
be introduced into the root zone in consultation with those TLD
managers as part of a request process.  I don't think anybody is
imagining we just throw all those things in willy nilly without
coordinating that with the TLD operators.

>>BARBARA ROSEMAN:  This is Barbara Roseman, general manager of IANA. 
Yes, the intent is that it would become part of our standard request
process, that anything that's in the ITAR now, once the root is signed,
we would make a request to them to those TLD operators, whether they
would like to submit that signing data for inclusion in the root zone.

 >>STEVE CROCKER:   Good.  Any other questions?  Anybody back behind
the post that we can't see so well?  No?  Okay.  Then I thank you all
of you for the presentations for the Ashley and for all the questions
and answers.  

Let's move on to the next step.  There was a symposium a couple weeks
ago, I guess two weeks ago today, tomorrow, rather, that focused on
some of the questions that have just been mentioned here about the
interactions between signing the root and the users of it.  And,
Suzanne, you're going to present the elements of what came out of that.

 >>SUZANNE WOOLF:   Yeah, thank you, Steve.  And thank you everybody
else, because that was a great handoff.  That was a beautiful setup for
what we're going through here.  And also, I have to apologize.  I did
prepare the slides -- wow -- did prepare the slides for a session with
the GAC yesterday.  But neither Steve nor the electrical in the room
are the only ones having technical glitches.  My laptop died yesterday
with a revised version of the presentation trapped aboard.  But we
persist.

Right.  Next.  

So, just to go from Steve's introduction, we did the symposium
sponsored by the DNSSEC coalition, which is an industry group comprised
of operators, registrars, implementers, ISPs, and others interested in
forwarding the widescale deployment of DNSSEC.  Also, Google was
gracious enough to host it at their facility in Reston.  

And we started with very closed -- it was a very close sort of
rigorous focus, get a small number of experts, practitioners and
protocol people and so on into the room with a very tight technical
focus.  Not so much DNSSEC deployment in general because there's a lot
of issues there over various time scales and scales of network
activity.  But we started with assume a signed root.  What's next? 
What has to happen before that will work?  Where do we go from there? 
Next, please.  Yeah, Steve has done this before with me.

The symposium attendees included root server operators, DNS
implementers, operators of signed TLDs, protocol people.  We had a
couple ISPs, registrars.  

And we focused on three major topic areas -- unintended consequences
of adding signed data to the root.  Because, when you're going to
change a complex system like this, things are always going to happen
that you didn't expect.  The key is to be prepared for them to
understand them in advance as much as possible and also to be prepared
to cope with the ones that were not necessarily fully foreseen.

The second area we looked at was key distribution, which Bill alluded
to briefly a little while ago.  The question of getting keys out into
the network and to network operators and DNS operators such that
assigned root is useful.  And we also looked briefly at the question of
key rollover for root zone keys.  Next.  Actually not next.  Can you go
back?  Thank you.

All we did is we introduced some questions and started to talk about
possible answers.  Most of the goal was to flag things we felt we
understood and to flag what needs further examination and review.  We
did decide early that the mechanics of signing the root, all the topics
that Ashley and Joe have been talking about, was out of scope for this
effort.  Because those are being dealt with within the process that
Ashley talked about small and is not -- so we wanted to move beyond
that.  We wanted to go to the next issue.  Next slide, please.  

So the first area we looked at -- I decided later I didn't -- I don't
like the term "avoiding unintended consequences" so much as "managing,"
because there are always going to be things you didn't expect.  The
principal framing questions we had were just around what happens to
different pieces of the DNS ecosystem as signed data appears from the
root down the tree.

Are there inputs on root servers to resolvers in the field, to other
network elements involved in DNS resolution and activities such as
firewalls and routers and many other devices that can become involved?

The primary result out of this discussion just came down to when the
root is designed, some network elements are going to see new DNS data. 
In some cases they're not going to fully understand what they see until
reconfigured or upgraded.  And that's a set of issues that network
operators and DNS operators will have to examine closely and be
prepared to manage.

Next?  The second major area we looked at was key distribution.  The
root zone DNSSEC public keys have to be easily available in absolutely
trustworthy ways for DNSSEC to be useful.  And it's not fully clear yet
how we're going to do that.  There are possible lessons from other
infrastructures already in operation on appropriate scales.  Microsoft
was gracious enough to talk a little bit about certificate authorities
and how they manage the infrastructure.  There's also the existing data
distribution mechanism by which you can -- by which people get the list
of root name servers.  And there are other infrastructures in that area
that we -- that we talked about briefly.

There are whole classes of obstacles to getting this right.  But
they're mostly things we already know about.  Upgrade software,
transport is not secure.  There's a need for maintenance being
introduced when you have keys that are changing.  There are expirations
and so on associated with keys that may not have been associated with
the infrastructure before.  Used to be you could set some of these
things up and forget about them.  When you have to maintain security
information, that's no longer true.

So the conclusion there was that the existing mechanisms are not going
to be adequate for the long term.  But we do have a basis for going
forward in the interim to -- in the interim kind of time scales we've
been talking about to be used as the basis for gathering experience. 
So we're going to need better solutions to some of these issues.  But
that's a long-term issue and there's no -- there's a basis for going
forward in the short-term.

Next?

The last area we looked at was key rollover, which, as a term of art,
just refers to how, when, and how often to change cryptographic keys. 
There are two pieces of that.  There's what's your policy and what are
your operational expectations?  In ordinary operational terms, when
things are behaving in their usual ways, there's also a different set
of assumptions and questions that apply to the possibility of an
emergency rollover or having to invoke an emergency procedure.  Key
management and rollover practice and expectations around operations for
keys is a very active area for experience and development of best
common practices.  This is already something that people -- TLD
operators who are signing their zones and enterprise operators who are
looking at designing their zones are looking at.  There are several
documents, I believe, in the DNS operations group of the IETF where
people are trying to work out what's the best way to approach these
questions.  We did -- we were very comfortable saying, I think fairly
quickly, that we do have to assume that even the infrequently used and
highly secure key signing key for the root will need a rollover
process.  It's not realistic to say we'll do that once and never in the
entire future history of the Internet have to do it again.

And we do need to have some further review and discussion around
exactly how to manage that and what that process -- what that set of
processes should be.  Next?

So sort of the takeaway, the bottom line here, we do have to be
realistic.  There are side effects to deploying DNSSEC in the root
because there are always side effects to changing a complex and dynamic
system like the infrastructure of the Internet.

There will be new processes and capabilities needed throughout the DNS
around deploying DNSSEC in the root.  Again, that's not just something
for the folks figuring out all the day-to-day operations of signing the
root to worry about.  There's a great deal of other things -- of other
work that has to be done and there are other parties involved in making
the technology useful.

And making it part of the everyday functions of the Internet much more
broadly.  Some of the issues are going to take some time to fully
characterize and resolve.  But we didn't find anything to make us think
that they can't be resolved.  We do believe they can be resolved.  And
that's where we're at.

 >>RUSS MUNDY:   Thank you.  Questions?  Yes, sir?

 >>MARKUS TRAVAILLE:   Yes, my name is Markus Travaille, of Dutch
registry. I'm aware of several TLDs making preparations to sign their
zones.  And what would you recommend?  To wait until the root is signed
and have all these effects a little bit damped out?  Or should they
continue as fast as possible with their preparations?  What's your
recommendation on that?

 >>SUZANNE WOOLF:   Well, I can give you my personal thoughts on that.
And I'm looking around the room and seeing a number of colleagues from
other TLDs and some of the folks that were part of the symposium.  And
I'd like to hear others also chime in. Because my sense of the answer
to that question is that going forward with deployment and gaining
operational experience, there's no reason to wait on signing the root
to do that.  Some TLDs have signed.  Others will be for their own
internal reasons on their own internal timelines regardless of what has
happening with the root.  IANA is maintaining the ITAR for signed TLDs,
so there's actually a great opportunity there for deployment
experience.  And for just gaining the operational know-how as quickly
as you reasonably can.

If it were me, I don't think I'd wait.  But I'd be curious about other
opinions.

 >>RUSS MUNDY:   I'd like to second that.  This is Russ.  From the
perspective of when you're -- it should match what fits your schedule
best.  And, if that means that it occurs before the root is signed,
fine.  If it's later, then fine.

But the first question should be what matches your implementation
schedule best.  Doing it beforehand I would see one of the significant
advantages of that is decreasing the number of variables that are out
of your control.  So, if, as you sign your TLD, you're pretty fully in
control of what occurs in that TLD and, if, when the unexpected events
do happen, because some will happen, you're going to most likely be in
a better posture to know exactly what changed when and to be able to
identify how to correct it or modify it.

 >>MARKUS TRAVAILLE:   Yeah.  Let me -- that was exactly a reason of
my question.  Because, if you have as a TLD a schedule that you're
about to implement at the same time the root is implemented, it's very
difficult for you to know if something happens whether it's reason of
your own implementation or whether it's the reason of the root being
signed.  That's exactly the reason I asked this question.  Whether you
should do it before or maybe at a later stage when all the root zoning
effects have been known.

 >>SUZANNE WOOLF:   Before or significantly after.  Not at the same
time.

There is sort of a basic system principle you don't want to be
changing too many things at once.  But maybe Alexa can comment on why
they didn't wait.

 >>ALEXA RAAD:   Thank you.  Very much I want to echo what Suzanne and
Russ said in terms of doing it before.  If you look around the room,
there's a number of ccTLDs that implemented DNSSEC and have actually
been working on it for longer, so they've got a lot of operational
experience.  And one of the reasons why dot org decided as a gTLD to do
it, to go ahead and sign their zone was expressly because we felt that
it was really going to help all the other folks that were in your
position who were simply looking to see, well, you know, what should I
do to give the industry the, if you will, the first domino that has to
fall before all the others fall.  And you know, signing of the root is
now inevitable.  It's going to happen.  The question is, you know,
where are the rest of the TLDs?  And what I term as stepping up and
helping the upgrade of the Internet.  And, if you can do it earlier,
all the best.  There's certainly a mechanism set up for you guys within
the DNSSEC coalition to take advantage of the operational experience of
a large number of folks that are in the chain without undo difficulty
and taxation of your resources.

 >>LANCE WOLAK:   This is Lance Wolak also from dot org, the public
interest registry.  There are a lot of practical reasons to start as
soon as possible ahead of the root being signed.  Think about all the
planning that goes into a DNSSEC upgrade, the development and eventual
launch.  You could be looking at a 2-year -- up to 2-year effort just
in that.  

Also, there are other issues that you'll need to work on such as the
registry to registrar interface, you know, getting your own registrars
up to speed on DNSSEC and what your plans are.  So look at all of the
practical issues that sit in front of you as a way to pace how you --
when you decide to move forward.

 >>BILL MANNING:   So there's one other, I guess, set of things.  This
is Bill Manning.  It's impossible to serialize the signing of zones. 
You can't take a number and wait until somebody else is done and then
you start.  That's one.  The second is that as soon as some of your
constituents, some of your clients that are downstream, you cannot
prevent them from picking up the data in the ITAR that IANA maintains
today.  And they're going to start seeing problems.  And they will call
you.  And they will ask questions about what's happening.  And so the
sooner you start, the sooner you're going to be able to answer the
questions about what's happening in the larger ecosystem of the DNS. 
It's not compartmentalized just to your TLD.

 >>MARKUS TRAVAILLE:   I'm sorry.  I have the impression you're trying
to convince me to start as soon -- we are working on it right now.  So
that's not the issue.  The issue is I would like to discuss here
whether it's good practice to implement something around the time the
root is being signed.  And I got a recommendation from you guys that
that's not a very good idea.  You should do it ahead.  That's what you
all recommend, which we're trying to do.  But I'm not sure if we're
able to because, as indicated, this is a complex project and it takes
time.  And, as we all heard a few weeks ago, the root is being signed a
lot earlier than some of us expected maybe.  So it's just a matter of
putting this on the table to see how other TLDs are working on this. 
And I'm just wondering if there's anybody here in the room who is not
as far in the -- we are just, you know, starting the preparations.  I
know dot org is already ahead of us and others have already
implemented.  But I was just wondering how the other TLDs are with
respect to this.

 >>STEVE CROCKER:   So a couple comments if I might.  In short order
you're going to hear from several TLDs who are in various stages.  So
there will be one effect of being here at this moment is you'll be able
to interact on that.  The other is that you can go very far down this
path on the things that you need to do completely independent of
whether or not the root is signed or not and whether that's put in.  If
there's any misunderstanding of the root, I think the uniform feeling
is that you ought to do that.  And, if you are concerned about an
entanglement or whether there's any complications that arise from that,
you can go all the way down the path to signing your zone and deploying
that without putting your key into the root, if you want to.  You can
defer that decision for some distance, untangle everything that you can
yourself.  And so I would not be fearful about the timing exactly. 
Because that will be a relatively easy thing to manage as things go
along.  The other thing is, despite whatever's said, trying to pin an
exact date on when the root is going to be signed and plan things
around that is probably not the optimum thing.  So I would just not put
any weight on that one way or the other.  It will happen when it happens.

 >>RUSS MUNDY:   This is Russ.  One more comment with respect to
planning and timing and so forth.  One of the things that I think that
the dot org activities paid strong attention to was some of the public
information aspects and keeping both those that were closely interested
in what was going on and those that were not so involved, providing
information to them and keeping information updated as it became
available so that expectations were reasonably set.  And, as Ashley
pointed out in her presentation, the -- getting the root signed this
year is a goal.  And this is what everybody would like to see, but it's
not a guarantee.  And I think that's a part of -- and an illustration
of a good how one ought to go about putting information in front of the
public so that they at least hopefully will understand.  You can never
guarantee understanding.  But at least so they'll hopefully understand
that this isn't guaranteed or put in stone and, especially if your
plans are of the nature that says we want to try to avoid a complete --
a simultaneous signing with the root.  And, if that causes yours to
change, if you have that information present as you put publicity out,
I think that also is very helpful.  Because those of us that are
technologists tend to maybe not pay as much attention as we should to
the public information aspects of this.

 >>STEVE CROCKER:   So good.  Yes?

>>JIANKANG YAO:  My name is Jiankang Yao from China.  It seems, if the
root is signed, I think many TLD operators will be -- not ready for the
signings of his own zone.  And technically or politically.  So my
question is -- after signing the root, what is the effects or results
for the unsigning the root or TLD operators?  Thank you.

 >>STEVE CROCKER:   No impact whatsoever.  No, that's by design. 
That, if you at least -- that is the intention and it is the effect of
the design that current unsigned zones will continue to operate exactly
as they are.  And there shouldn't be any difference there.  There is a
technical issue with respect to queries that are currently being made
to the root zone and what happens when the root is signed because the
DO bid is being sent.  And that's part of what Suzanne was talking
about.  But that's unrelated to whether or not the underlying TLD is
signed or unsigned.  So no issue whatsoever there.

 >>YUNGJIN SUH:   I'm Yungjin Suh from Korea.  When I'm introducing
the DNSSEC to our ISPs, I think of putting the root and the server to
the ISP, actually, ISPs to the resolver, catch server.  They ask me how
many times competent power needs to (inaudible)  Verify the DNSSEC. 
They should know to plan their budget to more investigate to handle
that.  So do you have any data about that?

 >>STEVE CROCKER: An excellent question.  There is already a certain
amount of data that's been collected on the impact on resolvers. 
There's a kind of an order that is developing of a lot of attention to
the signing process.  And then somewhat behind it is the attention to
the checking process and the deployment to that.  As I said, there's so
many experienced -- Comcast, Eutelia, and others have deployed
resolvers that are taking measurements.  

We're going to be in Seoul at your home next time.  And I think it
would be very natural for us to try to gather whatever data we can and
put a focus on that question.  And I look forward perhaps to working
with you on structuring that session.  Good.

>>JIANKANG YAO:  Another question.  After signing the root, you just
said there will be no effect on the unsigned root or TLD operators. 
Currently, many DNS client or DNS resolver will not -- will be not
updated to support DNSSEC.  But some DNS clients will be updated to
support DNSSEC.  Maybe some DNSSEC clients only support a DNSSEC
resolver -- resolver -- domain name resolver.  So for this kind of DNS
client maybe may find some unsigners who will be another  URL later.

 >>STEVE CROCKER:   No.  The -- we have to deal with the fact that
there will be many parts of the tree that are unsigned for some period
of time, for a long period of time.  So I think the picture that you're
painting, if I understood your question, is what would happen if
somebody implemented a DNS resolver, a client that insisted that every
answer be signed?  

And the answer to that is well, it would find very few signed -- as a
percentage, as a proportion of the total space of DNS only a small
fraction of the zones are currently signed.  And that was the way it
will be for a while.  So that will not be a very helpful strategy.  So
there's no expectation that somebody would implement a client that only
works with signed zones unless it was a very narrow specialized but not
a general purpose for some period of time.  We can hope for some day
down the road considerably where enough zones are signed so that that's
the natural expectation.  But we're still some distance away from that.

In other settings I've talked about broad phases where you have a few
isolated that are signed and then you have a few -- enough that you can
say it's sort of sparsely signed and some time later where the tree is
densely signed, we're so far away from that that it's not an issue yet.

 >>RUSS MUNDY:   Let me add something to that, if I could.  And that
is that many people tend to just combine the signing of some zone that
they may have authority and responsibility for with the activities of
users that they may have in their geographic space that are doing
resolution.  Those in reality from a technical perspective are
completely separate and separable activities.  And so, again, as people
are dealing with, especially the political and administrative higher
level people, I think it's important to try to make that
differentiation.  So, if you have a set of authoritative name servers
for a particular zone and you choose to sign the zone data and
establish it, that can be done completely independent of whether or not
anyone anywhere in the world, whether it's in your geographic area or
elsewhere makes use of the data.  And, in fact, if you choose to do
that, you then are operating at signed zone.  That doesn't mean that
anyone's making use of it.  Now, if, in fact, things are sort of the
opposite of that.  So, if the zone that you have authority for isn't a
signed zone, but you have some activities within your geographic space,
if you're, say, an ISP that's providing service and some of those
activities decide to send queries for DNSSEC information, they can do
that.  It's all part of the protocol.  It's all part of how it's built.
And there may be some effects from them sending queries that ask for
DNSSEC information.  And, again, it's completely independent and
separate from whether or not the zone you control is signed.  So I
think -- especially in dealing with policy level activities, it's good
to try to differentiate these things.  So, if the zone is signed and no
one ever makes use of the information in there for some X amount of
time, that still would not change the fact that the zone is signed. 

>>JIANKANG YAO:   So can I have a -- because the -- signing the root,
it is still possible, some resolvers or some DNSSEC client -- is the
only query or signed query about the DNSSEC information, although it is
a very low person, but it is -- I think that infiltrate, it will still
exist.  So -- so for this DNS client or DNS resolver will not resolve
the unsigned root zone or unsigned TLD operators?

>>STEVE CROCKER:   I'm puzzled about the direction of this because one
can build a piece of software to do whatever you want and if you --

>>JIANKANG YAO:   Because of the signed zone -- of the signed root --
zone, some TLD -- for example, this TLD is signed.  Just this TLD is
not signed.  I'm a DNS client, and maybe I -- it says -- only [incurs
DNSSEC information, so the zone signed, I get the information from
here, it's okay, it is true information.  If I get some information
from here, I will say it is now true information.  So from this point
we will -- for the client -- DNSSEC client view, so from me, for
example, me, this is a secret here or -- secret here -- zone, this is
another secret as this is not secret, so this for me is safe, this for
me is not safe.

>>STEVE CROCKER:   If you want to, you can do that.

>>JIANKANG YAO:   So -- so my question is:  After they sign the zone,
so I think that there will be effects on the Internet users, I think if
most of the TLD operators ready for sign the root, technically and
politically sign the root, then I think it may be better.  If it's a
only very small TLD signs the root, assigns the zone or the TLDs, there
will be, I think, some -- not very safe.

>>ROSS MUNDY:   Let me ask if we could maybe defer this discussion, I
have a presentation, it's actually last on the agenda, hopefully we'll
get there, about trust anchor repositories that gets into some of these
issues and perhaps that will help clarify some of them, I hope.

>>STEVE CROCKER:   Let me ask -- Jay had his hand up.

>>JAY DALEY:   I don't know of any DNS clients that would do that, we
can understand there will be an evolution of clients so that the very
end of that evolution may be that DNS clients only trust signed zones. 
So to get there I think there are likely to be some problems, you know,
there are bound to be.  But I think that the way those DNS clients work
and will change is still a relatively small community of people.  And
the prospect of seeing an unsigned zone being disenfranchised or cut
off because it's unsigned is either a very, very long way away or
something that just won't happen.  Because it can't happen tomorrow,
and so all the DNS clients that need to be able to support a mix of
signed and unsigned zones, so it's difficult to see how we would end up
in a position where people remove that support from it, you see?  So,
you know, the steps that are going to take us there should ensure that
if people leave a zone unsigned it will still work forever.  But I
can't guarantee it but I don't think it's going to be a big disaster.

>>STEVE CROCKER:   Jay, thank you.  Let me ask we cut this aspect of
the discussion off and it's easy to continue this discussion in various
ways, continuing.

Let me move on to a -- the first of a set of presentations about
activities in specific top-level domains and we'll start with Chris
Wright from the Australian registry.  Let me ask you to introduce
yourself and go forward.  I'm sorry?

>> (Speaker off microphone).

>>STEVE CROCKER:   We're good?

>>CHRIS WRIGHT:   Hello, my name is Chris Wright.  I'm the CTO of
AusRegistry, we're the dot au registry operator.  So we operate the
registry for the second-level domains in au, com au, net au, org au, et
cetera.  There are a lot of TLD operators that want to speak, so I'm
going to speed through this as quickly as possible.  I've also got a
little bit of a technical demonstration at the end.  I apologize to the
nontechnical people in the room but I'll just quickly get to that.  

So I'll quickly speed past who AusRegistry is.  You guys probably have
heard someone from AusRegistry speak before, but we're the TLD operator
for au, effectively.  

DNSSEC for domain name registries can be broken down into two parts
that need to be implemented.  One is actually DNSSEC signing your own
zone.  So for us that would be signing dot au, com dot au net dot au
org dot au, and the other is enabling registrants to publish DNS
records so their public keys into your zone.  

The implementation of each of these is proceeding independently of
each other in dot au but both are required to have fully functional
useful implementation of DNSSEC in dot au.  

So our current work currently from the perspective of signing the dot
au and the 2LD zones, we've completed most of our experimentation and
research.  At the moment we're looking into -- key management is the
biggest focus for us mainly around HSMs and experimenting with various
different types of HSMs.  We still need to do some final work on our
key rollover policies, that's being done in conjunction with auDA, the
regulator.  

And the subject that was debated a lot in the ccNSO tech day on
Monday, we dynamically update our zone, we don't do zone file
generations, so we had to work out how to make DNSSEC signing work with
dynamically updated zone and I'll get to that a little bit later with a
demonstration.

From the perspective of enabling registrants to publish their public
key into our zone files, we've completed our experimentation and
research there.  We've implemented the IETF EPP extensions as I expect
most TLD operators will end up doing eventually.  There are a few other
registrar interface effects that you need to consider.  Most TLDs now
also have a web-based interface, so the modifications need to be done
there.  There are also things you need to think about in terms of, for
example, when domain names are transferred from one registrar to
another.  Typically that also involves where registrars are also doing
DNS hosting, a change of DNS servers from one registrar to another, if
someone has DNSSEC-enabled their zone, a way to do that, without
leaving the registrant with a period of insecurity, so with the
transfer request, the way that we've solved that is that with a
transfer request the gaining registrar can also send through the new
public key information to be published simultaneously with the old
public key information.  So this will allow a seamless transfer and a
seamless cutover for registrants transferring from one registrar to
another.  

Obviously, the registry tool kits that we offer need to be modified
and the last part was sending DS records in dynamic updates, that's
actually been the part that's given us the most trouble.  Most of the
libraries that we use for implementing dynamic updates don't support
sending DNS records, so that's the last part that we've got left to
resolve.  

So our next steps that we've got left to do, complete our research
into HSMs and pick a brand and start using it.  We have to get signoff
from auDA on the key management policies and how that's going to work. 
There's probably going to be a fair bit of public consultation or at
least consultation with other security experts in au to get their buyin
on that process.  We need to embark on a registrar education campaign. 
DNSSEC significantly changes the dynamics of the interaction between
registrants and registrars as well as between registrar and registry. 
Previous -- previously, the registrar would interact with the
registrant only when the registrant wanted to make changes and perhaps,
then, that renewal time for domains -- which in au that's for two
years, domains are registered for two years only -- all of a sudden now
the registrar-registrant interaction will need to occur every time a
key rollover needs to take place and depending on the way the
registrant has done that, whether they're using key signing keys or end
signing keys or they'll only using a single key, that could be as
frequent as (speaking too fast).

>>STEVE CROCKER:   You're overrunning the scribes here, can you slow
down a little bit?

>>CHRIS WRIGHT:   I'm sorry, I have a habit of speaking too fast. 
I'll try and slow down a little.  Yeah, so registrants may need to
interact much more frequently with registrars than previously was
required.  Interacting with governments and ISPs, we've had a few
industry meetings with ISPs in Australia trying to get them to buy into
the DNSSEC process and enable DNSSEC on their infrastructure.  But
again, there's an education campaign that needs to happen there and get
these ISPs aware of what it means and what the effects will be for them
doing it and also try and educate them as to why it's a good thing for
them to do it.  

Public education campaign, if we're going to go ahead and do this,
it's not going to be much good if, at the end of the day, end users
aren't going to use it.  So we want the public to -- especially larger
organizations, to go to registrars and actually request that they use
DNSSEC, otherwise there won't be any impetus for registrars to build
DNSSEC interfaces.  

So currently we're looking at having a -- published signed versions of
the zones simultaneously with unsigned versions around Q3 of this year
and perhaps a full go-live around Q4 of 2009, although a lot of this is
still dependent on getting those other those entities involved and
wanting to work with us to make it happen.

So now I'm just going to flip over, and this may or may not be
interesting for all of you.  My purpose here was to show that for
anybody who's contemplating implementing DNSSEC, that it doesn't have
to be troublesome, it doesn't have to be complicated.  It's actually
relatively easy.  And even with us using dynamic updates, in my
opinion, it's actually a little bit easier.  

So I'll just flip over to a screen here.  I hope the font is readable,
which it's not.  So let me just quickly resolve that issue.  Just one
second.

That's a bit more readable.  So within dot au, we dynamically update
our zone, as I've said before, so the whole purpose here is -- what I'm
going to show you guys is that I'm going to go from an unsigned zone to
a fully functional signed zone without taking the zone offline, without
shutting down our name servers without doing any sort of key signing
processes offline and then I'll show you how dynamically updating that
zone can be done without having to take, again, take the zone offline
and re-sign any changes that come in.  

Just got another screen over here that will also up the font size on
it and drag across.  

So in the system here, at the moment, what we have is a simple com dot
TLD zone, and as you can see, there's a couple of example domains in
there, business and company down here, you can see.  You'll notice
there's no DNSSEC signed records in there at this point in time.  

So if I flip over to here and run my initial sign process, I'll just
quickly step you through what it's doing, so all it did there was it
generated two keys using typical BIND tools, DNSSEC keyed in and it
generated two dynamic update requests there that it's prompting for me
to send over to that server.  So once I hit enter here, that's now sent
those two updates through to that server.  Don't worry too much if all
of this stuff is a little bit difficult to understand.  But the point
here is that that name server is still up, it's still running, it's
still responding, and it hasn't been taken offline.  I'm just going to
grab this because I'll need it later.  That's the file name for my zone
signing key.  So if I now flip back over to the other screen here and
get BIND to write out the current -- so the first thing to show there
is that what BIND's actually done is written all that information into
a journal file as it does when you dynamically update, so I'm just
going to make BIND write out its journal files.  And we'll open up our
zone file again.  And you'll see that now all of the DNSSEC information
has been added into that zone.  And what you guys are probably
surprised to see is that script that I ran actually only had three
commands in it, so it was three commands from the command line that
were run to actually cause this zone to now be signed with both the
zone signing key and a key signing key.  So that's a relatively simple
process that's easy to implement.  

Now, if I thaw that zone out, those of you who are technical will know
what that means, and I flip over to my registry interface, what I'll do
now is I'll just very quickly create a -- this display isn't very good
up here -- I'll very quickly just create a domain in that zone.  Whoa,
if I know the password.

[ Laughter ]

>>SUZANNE WOOLF:   BIND is not known for being pretty when it does
these things but it does work.

>>CHRIS WRIGHT:   I can't see a damn thing.  Maybe I'll just drag this
over onto my screen so I can see properly.  I'm just going to create a
domain called demo.com.tld.  And what we'll do is quickly assign name
servers to that domain and you'll see how, again, very easily it all
just works.  There's nothing to be scared of.  There's no --
extensions.  Damn these things.  And anybody -- TLD operator out there
that's worried about implementing these or hesitant to do so because
they may have to sacrifice some of their functionality, don't be.  You
can pretty much do anything with a signed zone that you can do with an
unsigned zone, so there's not too many things to worry about.

So we'll just quickly assign ns1.example.com and ns2.example.com to
our domain that we've created, so if I jump back -- I can probably do
it here, actually.  

The other window.  So this is just the log file there of our dynamic
update daemon.  And as I assign these name servers to the zone, you
should see the updates fly through the log there and then we'll be able
to check that they actually entered into the zone, if I learn to type
correctly.  Wish you could see what I was typing on this screen so that
you weren't bored.  

So that update just went through there and there were those two
updates being dynamically sent to the name server for those two name
servers that I added to that zone.  If I change back to my other screen
over here and we tell BIND to write out those journals, again, and we
open up our zone file again, some are in here, should be that demo
domain that I just created, which here it is, with its new name server
records now being added into the file and the appropriate NSEC and
RRSIG records there above it.  

And the final part, if you guys bear with me for two more minutes, is
key rollover.  So there are two main ways of doing key rollover.  One
is prepublishing and the other is double signing.  They can both be
done dynamically without taking the zone offline.  I'm just going to
quickly demonstrate double signing because that's the easiest of the
two to demonstrate.  But if you go back into our zone here at the
moment, you'll see that there's only one RRSIG record for each record,
so the zone's only been signed once.  

If we now just run double sign rollover -- wrong screen -- double sign
rollover part one, so part one here has just generated a new zone
signing key and it's asking me if I want to add that with a dynamic
update to the zone.  So that's now sent through that dynamic update. 
And that's probably broken because that zone was frozen, but we'll see
what happens.  May have done that.  That's my fault.  Now that the zone
is full, we'll try again.

All right, so now you should see the multiple RRSIG records there
generated so now the zone's double signed with two keys.  And we would
normally wait a little bit for the zone caching processes and so forth
to go through, we would publish our new DS record in the parent zone. 
And once we were sure that our old DS record had been removed from all
the caches out there on the Internet, we would run the second part of
our process which is to part two which is to remove the old key, which
I copied before.  

So now that's going to delete the old key from the file and BIND will
automatically go through and remove all of the NSEC and RRSIG records
that relate to that key.  There's a lot of freezing and thawing out
going on here, but that's okay. 

So you'll see there's only one RRSIG record per zone.  

So we have successfully rolled over the keys without taking -- so
we've gone from an unsigned zone to a signed zone and then rolled over
the keys without taking the zone offline at all, without stopping BIND,
without having to do any sort of processes like that and successfully
dynamically updated the zone.  

And the surprising thing that you guys will probably -- if anybody
wants to come and see me later, I'll show you, is each of those scripts
that are run there are only actually contains two or three lines of
commands to run and most of those lines can actually be shortcut if you
generate your keys elsewhere.  

Now, the one drawback of all of this is that your name server has to
have access to the private key.  In order for BIND to do these things
dynamically online without taking the zone offline, it does need access
to that private key and that's why we're investigating the use of HSNs.
There's a code in BIND at the moment that does allow it to communicate
with HSNs.  It is a little bit crude, it's being improved, it's very
undocumented, but if you scroll through it, you can get it to work.  We
have got it to work and it does work, I guess is the main point there.  

So that's it for me.  I hope I didn't take too much time and happy to
answer any questions, if there are any, but my overall point is don't
be scared by it, it does work, and it is relatively easy, so that's it,
thank you.

>>STEVE CROCKER:   Thank you.  Questions?

>>ROY ARENDS:   Yes, Roy Arends -- oh, I'm sorry.

>>STEVE CROCKER:   Way back in the corner.

>>ROY ARENDS:   Ray Arends, Nominet.  First of all, Chris, I have to
say you're very, very brave in doing this live on the screen here.  I
want to thank you for that.  

My question is a very simple technical question:  What version of BIND
are you using for this?

>>CHRIS WRIGHT:   Not the version I wanted to, actually, because
something I didn't get to mention that I should have mentioned is that
there are a couple of resource records that you need to be aware of
when you're doing this.  One is a resource record called Type 65537 or
something, and this is a resource record that is inserted by BIND that
you can query to find the status.  Obviously, that zone there was very
small.  Larger zones like our com dot au zone which has got 1.1 million
domains in it, that -- that process doesn't happen instantly, obviously
BIND takes a bit of time to go through and sign all those zones.  That
resource record can be queried to find out how far BIND is through the
process of signing the zone and when it is completed.  

Another resource record -- long-winded answer to your question, I'm
sorry -- another resource record is the NSEC3 param resource record
which tells BIND how to generate, you know, NSEC3 records just salt
that you wanted and those sort of things.  I actually wanted to
demonstrate that, but the version of BIND that I'm using ignores the
NSEC3 param resource record at the moment, it wasn't the version that I
wanted.  That version is, if -- why is my typing not appearing on my
screen?

>>SUZANNE WOOLF:   The other thing to know about BIND support for all
these wonderful things is that the support will be both more -- more
mature and better documented in the next version of BIND, 9.7.

>>CHRIS WRIGHT:   So the version I'm using here is 960P1 so it's
actually just the standard Red Hat RPM that comes up with the Red Hat
Enterprise NX5. 

>>ROY ARENDS:  Thank you, Chris.  Another quick one, sorry, if I may
ask.  I understand that you're currently testing with HSMs.  Have you
tested the BIND tools with HSMs and if so, maybe we can talk afterwards
about this.  I'd be interested in that.

>>CHRIS WRIGHT:   When you say BIND tools you mean the --  like dnssec-
keygen and those sort of tools?

>>ROY ARENDS:   The tools that you now just showed on the screen, the
tools that you're hoping to use when we actually go live.

>>CHRIS WRIGHT:   Yes, they're the exact tools we're trying to get to
work with HSMs, yes.

>>ROY ARENDS:   Okay, thank you.

>>STEVE CROCKER:   There's a question in the corner there, I think we
need a microphone, do we have anybody with a roving mic?

>>DANNY AERTS:  Hi, Steve.  My name is Danny Aerts, I'm responsible
for dot se.  We signed the zone 2005, I think, that we started working
with registrars 2007.  One thing I thought about when I heard your
presentation is the dynamic update, dynamic update.  Because if you
look at the situation we have now with -- 20% of our registrars work
with DNSSEC and they have the ability to handle about 40% of the
domains.  Where we are right now is we're still in the testing phase,
we have about 2,000 domains in our system.  And we're looking at how
they're handled between the registrars.  Our mission is to go between
50 and 100,000 domains this year.  But I'm very happy that I don't have
any dynamic update right now.  It gives me an opportunity to monitor
the registrar handling of the keys because that's where the problems
occur.

 >>RUSS MUNDY:   Thank you, Danny.

>>JIM GALVIN:  One quick question for Chris.  I don't know if you've
looked at putting some of the scripts and such into the open source. 
There's a number of activities around the network that have provided
open source support. and we do DNSSEC tools.  We'd be happy to look at
incorporating some of your things, if you don't want to look at
supporting it.  I'm sure there are others, I know Nominet has done some
things and LNET Lab has done some things.  So, if it's something that's
in consideration, I would urge to you get in touch with somebody so
that other folks can make use of the fine work you've done.

>>No worries.  Thank you.

 >>ROY ARENDS:   Can I just butt into that?  Thank you.  So IIS and
Nominet are currently combining their development efforts to create a
solution called open DNSSEC.  There's a site, open DNSSEC.org.  If you
want more information, that's the place to go.  So I'm just referring
to the information you just gave.  Thank you.

 >>STEVE CROCKER:   Good to hear.  Thank you very much, Chris.  This
is exciting stuff.  Let me move on to an update on the dot org DNSSEC
activity.  Who's presenting this?  Of course, Lance. Excuse me.  I knew
that.  Lance Wolak.

 >>LANCE WOLAK:   Thank you, Steve.  As Steve mentioned, I'm Lance. 
And I'm the director of product management and marketing with dot org,
the public interest registry.  

Next slide, please.  This is my third update in this ICANN session. 
And we'll give you just a progress update this time.  I will review
some of the items that I discussed the last two ICANN sessions in a
wrap-up of this.   

So we signed our zone on June 2nd.  We're the first open gTLD to
successfully sign the zone.  And this is a significant milestone in our
industry.  Again, being one of the original gTLDs, we have over 7 1/2
million names under management.  And this occurred -- this zone signing
occurred without incident and no user complaints to date and no ill
effects on our entire zone.

So the dot org zone is signed.  What's next?  We've kicked off our
friends and family test period.  That's our name for our beta test
phase.  

We have three test domains that we're currently doing testing with at
the moment.  With these test domains we've manually inserted DS test
records for these.  And we have a number of folks testing these.  We're
observing the behavior around the queries on these test domains.  And I
think in a future session we can provide technology or systems lesson
learned overview where we can share information on the observed
behavior, the system loads, and also share our conclusions on the root
causes of these observed behaviors.  

By the way, the DNSSEC coalition will have this information to share
among its members.  So check back with the coalition in 30 days.  We
plan to include other test domains within the next few weeks.  These
test domains are not pointing to live websites.  We wanted to start
first with a very controlled environment for our testing.  And, as we
observed the behavior and reach our success criteria on that, we'll
expand the scope a bit to begin to include domains with live websites
and eventually move to more visible domains.  We've had requests from
dot orgs to include their names in our beta test phase.  We plan to do
that.  But, during this first phase, we're doing just these test
domains.  If you want to be included and you have not yet registered
with us, contact Lauren Price, who is our DNSSEC manager.  Her email
address is on this presentation.

We expect to reach full production readiness in 2010 for all
registrars and registrants wanting to sign their zones.  We don't have
the specific date applied to that yet.  And towards the fourth quarter
of this year, we should have a time frame within 2010 narrowed down. 
The dot IRQ was submitted to the ITAR on June 19th, and we expect it
will be signed in approximately a week from that date.  

We continue to do significant outreach on our DNSSEC program.  As Russ
had mentioned earlier, it's not just the technology effort involved but
communication and engaging with those within the industry as well as
outside the industry.

One of the things we did in April was we went to a -- we actually
conducted a DNSSEC workshop at the nonprofit technology conference that
was held in San Francisco to inform dot org domain holders on the
importance and value of DNSSEC.  There's a lot of fundraising activity
and a lot of traffic on dot orgs, specifically for this community, the
nonprofit community.  DNSSEC certainly will be a vital enabler for
them.  We also held a DNSSEC panel at the 2009 RSA conference.  We
launched a DNSSEC resource center on our own Web site.  We're doing
regular blog updates on DNSSEC.  Information and news, our blogs are
getting reposted through several other industry blogs. Again, the
coalition continues to grow and increase the awareness and adoption of
DNSSEC.  If there's anyone in the room who's not yet part of the
coalition, I strongly encourage you to join that organization.

Before I get through it -- this is my last slide.  But, before I get
through that, I get asked a lot of questions -- you know, what lessons
have you learned to date with your implementation of DNSSEC?  So I
wanted to share some of those with you.  It's a bit off script here
with the presentation.  But these are more or less program level
lessons learned.  

First and foremost, your DNSSEC effort.  Please consider that more
than a technology implementation.  This is a  large-scale product
rollout.  And you really need to apply appropriate program management
discipline to it.  So, for example, in addition to the technology plans
that you put in place, please keep your marketing organizations in tune
with what you're doing, engage them early.  Review and sign-off their
communication plans.  You will get a lot of press inquiries with each
milestone that you reach in your DNSSEC program.  And you really need
to have the communication plans in place prior to those milestones.

Second item:  Don't put any artificial launch dates on your DNSSEC
program.  That was something we decided right at the very beginning.  

Most importantly, let technology readiness drive the launch dates and
not your PR department.  So, as you all know, in any software
development organization, if you put out a launch date and you're
pressured to achieve a specific launch date, as you get close to the
launch date, you may fall into the trap of descoping or defeaturing
what you're offering in order to preserve the launch date.  Again, my
strong message is let the technology readiness drive any of your launch
dates or interim phase dates.  

And generally stick to general time frames.  When we were reviewing
our DNSSEC progress at a prior ICANN conference, we were in the month
of March, beginning of March.  And we're still being asked when we're
going to sign our zone.  And we continue to just say sometime in the
first half of 2009.  We were actually very, very close to signing it at
that time.  But, again, with the typical risk assessments and
technology readiness reviews that we do on a regular basis, we did not
want to announce anything, force any artificial dates on the launch or
the signing of the zone.

Another important lesson learned from a program perspective, break
your DNSSEC program up into coordinated phases with very measurable
goals.  Do reviews at the end of each phase conducting extensive risk
assessments.  Not everybody in this room wants to be the first in their
segment of the industry to implement DNSSEC sec.  If you're considering
using a DNSSEC upgrade, use this early adopter fear to drive your own
extensive risk assessments in a very cautious approach.  With each
phase that we've been through in our own development, we've done really
significant risk assessments looking at all the things that could
possibly go wrong and then planning around that.  And, as a result,
we've had very, very good success so far.  And we've been ready to
respond to any specific problems should that have come up.  Finally,
join the DNSSEC industry coalition.  There are several working groups
within this coalition and a very large knowledge base to pull from.  So
learn from others participating in this knowledge sharing.  There's a
lot of combined experience.  There's a lot of very good practical
things to gain from the coalition -- toolkits, documentation, lessons
learned on registrar engagements, and so forth.  So very strong
encouragement on the DNSSEC coalition.

There's my contact information on this slide.  Please give me a shout
if you want any additional information on our DNSSEC program or if you
want to learn more about the DNSSEC coalition.  Also, if you have any
domains, test domains or live domains that you'd like to include in our
beta test phase.  Thank you.

 >>STEVE CROCKER:   That's great.  Thank you.  So everybody's watching
the very large important development at dot org.

Any questions for Lance on the rollout of dot org?

 >>ROY ARENDS:   Lance, hi, this is Roy Arends.  I've got a question
of NSEC3 versus NSEC.  Do you think there was a difference rolling out
NSEC3 as opposed to, for instance, what you would have done with NSEC? 
Thank you.

 >>LANCE WOLAK:   I'm going to turn this to Jim Galvin with Afilias. 
I'm going to put him on the spot here.  I have a short answer, but I'll
let Jim go ahead.

 >>JIM GALVIN:   I was whispering in your ear saying I think it was
really a policy question.  Yes, it means obviously an implementation
issue.  It didn't really slow anything down.  We waited for it.  And,
when it was ready, we just went forward with it.

>>BARBARA FRASER:  Barbara Fraser.  I'm on the board with PIR.  And we
were sitting behind the staff of PIR really shoving them hard in this
direction.  But I would say that, actually, you know, the NSEC3 was --
we waited for it for -- the primary reason was we wanted to be able to
avoid the tree walking problem.  So that was why we, as the public
interest registry, opted to go that direction.  I mean, even though it
was cutting out capability that was currently capable without moving in
that direction.  So we did wait.  And, because of that, we had to wait
for the NSEC3 software to be ready.  And we were almost ready to deploy
a little bit earlier than we did.  And the NSEC software had to be
revved again.  So I would say that it did impact the time of deployment
to when we actually got the zone signed.  But that was our reason. 
And, again, I give my best regards to PIR staff and to Afilias for
putting up with the board really shoving at them.  And, as Lance said,
you do want to do this in a very deliberate careful fashion.

 >>ROY ARENDS:   Thank you, yes.  I just did want to point out that
dot org is not only one of the largest but probably the only one that
uses NSEC3 right now, right?  

(Speaker off microphone.)

>>ROY ARENDS:  I'm sorry.  I apologize.

 >>RUSS MUNDY:   I don't think was on the transcript, but dot gov is
also NSEC3 signed.

 >>STEVE CROCKER:   Any other comments?  Yes.

 >>JIAKANG YAO:   How big of the zone size are the signed DNSSEC for
dot org?

 >>LANCE WOLAK:   Yeah, we're at 7 1/2 million names, domains under
management.

>>I don't think that's what he was asking.  

>>JIANKANG YAO:  How big of the megabytes of the zone file?

 >>LANCE WOLAK:   You know, I don't have that number in front of me. 
But it's not that much larger.  There's no signed delegations except
for the three that Lance had, the test zones.  So the zone file itself
has increased very little.

 >>STEVE CROCKER:   Thanks, Jim.  Good.  We've come to the wonderful
point in the program where we get to take a break.  We're going to
start up again in 15 minutes at 11:00.  Please come back.  Please
reassemble.  There's noise outside, which I presume is accompanied by
coffee and so forth.  And then we have quite a few more talks to
continue with.  Thank you very much.

[Break] 

 >>JIM GALVIN:   If we could ask folks to come in and sit down and get
ready, please.  We can get started again.  Once again, please, if we
could ask folks to take a seat.  Maybe pull the doors closed please at
each end.

 >>RUSS MUNDY:   We'll be starting in a minute or less.

 >>STEVE CROCKER:   How about less?

>>RUSS MUNDY:  Sounds good.  Let's go.

 >>STEVE CROCKER:   Okay, we begin the second half of our session. 
And very pleased to have -- I'm going to -- I hope I get this right --
Lai Heng Choong presenting on the test bed for Malaysia.  And let me
turn things over to you.

 >>LAI HENG CHOONG:   First of all, I would like to have a big thanks
to the organizations to invite my dot my domain registry for these
presentations.  And also thanks, Steve, because I'm sitting in your
chair now.  

So the topic that I would like to share today is dot my DNSSEC closed
test bed.  

The objective for this dot my DNSSEC test bed is to raise awareness on
DNSSEC technology in Malaysia and to anticipate potential development
issues and also to form a best practice policy and especially with
regards to the key management and to gather feedback from the
participants for improvement of our productions environment later on.  

Okay.  This is very brief architecture for our test bed.  So,
basically, we have set up server, some cross environments.  The first
thing is to authorize the server for dot my zone, dot my zone.  And
then we have a signer.  We have a key generator for our dot my and dot
my zone. And of course we have a Web server for the tester to manage
their domain names and also the database server.  

So below that the red color one is the IANA DNSSEC test bed root
server, which we have passed our DSkey encrypt into the IANA.zone. 
And, of course, we also set up a DNS caching server for the validation
purposes.

And for the participants, they need to set up their own DNS, which is
the primary DNS and the secondary DNS.  So this on their own.  So this
is a brief architecture for the test bed.  

And this is the test bed hierarchy, which we can see that the change
(inaudible) is up to the dot zone -- the root zone, which is the IANA
DNSSEC test bed root server.

So for the signing process -- so it's  first the user or the
participant needs to register their domain names.  And, of course, they
need to assign a DNS server for the domain name dot register.  So
through our web interface.  

So, after they register the domain name, they need to sign the zone,
the domain zone in the DNS server.  And, of course, after signing the
zone, then you have DSkey or the DS record.  So our system will
automatically capture the DS fingerprint or DS record and insert it
into our database.  

So with all this information, which is the domain names, the NS record
and the DS key for the domain names, so we will use it to generate --
at first we need the NS key and the domain name to generate the
(inaudible) file for dot my.  And then another process will be grab all
the DS key for all the signed domain names and put it into a DSX file
for all the domain names.  And, of course, the other server we'll
generate our dot my key, which is ZSK and KSK.  So with all this
information we'll pass to a signer server.  And then we sign a dot my
zone and produce the signed zone.

So, basically, this is how the process looks like.  So for our key
information, so we are using a KSK and ZSK for our dot my and dot net
dot my zone.  So the algorithm would be RSA-SHA1 and RSA-SHA256.  And
the key length is 2048 for our KSK and 1024 for our ZSK.  And,
basically, we're using a bi-utilities, which is DNS-set key gens to
generate pur dot my and dot net dot my zone.  The KSK and ZSK.  And DNS
asks them to sign our dot my zone.  

So how to participate to our test bed.  So there's very simple five
steps.  The first is you need to register as a participant.  So then
you need to log into our Web site and add a domain name.  And then
after that you need to sign your zone.  And submit your DS key to a
parent zone.  So, basically, submit your key means in the interface you
just click your button.  So our system we automatically courier DNS and
grab your DNS set into our database.  

So after that you will need to check your domain names for whether it
is validated or not.

So this is an interface that we developed for the -- for our test bed.
So the URL is www.dnssec.my.  So you need to create an account.  So,
after create an account, you need to go through your applications.  And
we'll approve it and add it in your account.  You will receive an e-
mail.  And then after that you can log in to the test bed by the user
name and the password.  

So, after you log in, you can add a domain name.  This is a screen
name that you can add your domain names for the test bed.  And then, of
course, you need to assign a DNS for your test domain names.  

So in here we also create a user option for the user for if the user
are not familiar with setting up their own DNS server.  So we're
offering the DNS hosting for the domain names.  So they can choose to
use our domain names, sorry, our DNS server, which is ns1.dnshost.my
and ns2.dnshost.my.

So in this case they just need to register their domain name with the
DNS server.  And our DNS will automatically find the domain name, the
zone for the domain name and let the user, the participant to manage
the domain names there.

So, of course, we have the DNS management screen.  This is a screen
for the user or for the participant to log in and see their DS key.  

So this is how the screen or the DNSSEC management screen looks like. 
So, if the domain names is signed, so our system will request -- will
query the DNSSEC, the DNS server and grab the DS record and put it into
the database.  And the user or the tester can log into this screen and
see that DS record.  So, basically, we are pretty much follow the dot
se model.  So first we have developed key management tools for the
user.  So this is only available for those participants or the tester
to using our host domain, the test domain in our DNS.  So in our DNS we
have a system to sign a zone and let them to sign the domain zone as
well.  So this is just for the user to experience the rollover process.

So, after the signer zone and they pass the DS key to our dot my zone,
the parent zone, so they need to validate the domains.  So, basically,
they can use a Unix, which is a dig command.  So the red color one is
the command they need to use to validate their domain names.  So the
expected result should have an "ad" flag in the header sections for the
answer.  That means the zone or the domain names is authenticated data.
The answer is authenticated data.  So, if the users set up their own
DNS cache server, then they can put -- they can put the IP address here
to -- with the DNS cache server.  All the instructions are how to trust
the key, the published key for the dot my zone will be encrypted in the
Web site.  So they just need to copy and put it into their (inaudible)
server.  And then they can become a validation server.

Okay.  

So this is the dig result, how the dig result looks like.  As we can
see, there's a defect for this test domain.  And this screen shows that
the cache server actually pointing to the IANA test -- DNS test bed
server.  

So for validations using Windows 7, you can just go in to change the
Windows server name resolution policy table.  This all the instruction
that exists can go to the start.  And then in the search program in the
file text box, you type gpedit.msc.  And then you have a screen.  And
you need to create a name resolutions policy and just follow the screen
below.  So this is how the screen should look like.  So, basically, you
just need to enable the DNSSEC in the root.  So then you put in your
DNS validation server, DNS cache server.  And then here you are.  So
this is the table that tells you that dot my has been DNS enabled.  And
with that you can just go to the browser and type your domain names or
your test domain names.  And, if you can go to the Web site or put your
query for the A or for dot my is DNSSEC validated.  

So, as a conclusion, so dot my DNSSEC test bed already a participant
in IANA DNSSEC test bed.  And we have 16 participants until last month,
up to last month.  So seven of them are ccTLD which is Korea, Mongolia,
China, Singapore, Hong Kong, Sweden, and Austria.  So a big thanks to
them to join us now for this test bed.  

And so our expectations, we expect to get more ISP involvement in the
dot my DNSSEC test bed.  And we hope that we can open the dot my DNSSEC
test bed to public trial in Q4 this year.  We hope that we can do a
dynamic update for them for the public trial.  And to have a DNSSEC in
our productions by next year.  So this is for my presentation.  Thank
you.  Yeah.

 >>RUSS MUNDY:   Okay.  So do we have any questions?  I don't see any
hands from the audience.  But I do have one for you.  Is your test bed
open for other than TLD participants?

 >>LAI HENG CHOONG:   Because this is a closed test bed, so at the
moment not.  Because we sent invitations to all the participants
(inaudible.)

 >>RUSS MUNDY:   Okay.  Thank you.

 >>STEVE CROCKER:   I'll chime in with a question.  Can you say
something about what your expected schedule is going forward and when
you might be completely live and fully operational?

 >>LAI HENG CHOONG:   Okay.  So, yeah.  So in this screen we can see
that -- this is our plan now.  So we hope that -- because we are going
to open for the public trial.  This is closed trial.  So there's
another trial for all the public.  So we hope that we can open it this
Q4.  And then after that by next year we will put it into the
productions.

 >>RUSS MUNDY:   Okay.  Thank you very much.  Let's see.  Is Steve
going to drive the computer again for the next presentation?  That
would be Jay.

 >>RUSS MUNDY:   Jay is next.  So, as soon as Steve gets the slides
changed here --

>>ROSS MUNDY:   So those that have remember Jay Daley from an earlier
position, welcome and congratulations for your move halfway around the
world.  And he's going to tell us what's happening with New Zealand.

>>JAY DALEY:   Thank you, Russ.  I'm not going to talk about
technology at all, just about policy.  And the nice thing for me is
that I don't really have to deal with the policy at my new job.  This
has to be dealt with by the regulator.  So what I'm going to do is pose
lots of hard questions for the regulator and if anybody has any other
questions, please let me know.  In fact, I may even pay if you have
some very good ones.  So next slide then, please, Steve.

>>ANDY LINTON:  I'm happy to pay for them.

>>JAY DALEY:   These are some of the bigger issues that drive our
consideration of policy, how do we turn DNSSEC off or what happens if
somebody has to turn DNSSEC off, how do people manage keys which are
new, important things that people have difficulty with dealing in
ordinary circumstances like fun doors and things like that and now have
to deal with them in a technological way, what are the expectations
that people have of security, how many people really understand DNSSEC
and implications of it and what are the cost issues for us.  Next
slide, please.

So looking at registrars, then, there are new obligations on
registrars that never existed before.  A registrar can't introduce
DNSSEC for a customer and then suddenly change their mind to withdraw
that service.  That would be disastrous.  They have to think very
differently about processes.  They can't just restore from a backup
because they never know whether signatures will still be in date or all
sorts of things.  They have to consider security standards for the way
they manage keys.  If we envisage a mechanism where registrars hold
private keys then we have to think about what happens when a registrant
moves to a different registrar, do the keys move with them.  Do we have
to force registrars to cooperate with a key rollover in such a
circumstance or do we insist that registrars place keys in escrow so
that when it moves, we can move the keys with them.  And how do we deal
with noncooperative registrars.  For example, under registrar failure
or when we're expelling a registrar, you know, all of which may lead us
to, for a registrant, having quite a serious problem, much more serious
than they would have right now.  Next slide, then, please.

For registrants, big issue, once DNSSEC is enabled, currently it's a
one-way trip, they can't just change their mind on this, they might,
then, find that they have a restricted market in registrars that they
can move to so if there's any one registrar in the country or one that
has now implemented DNSSEC and they turn it on then they're stuck with
that registrar until there's a greater market there for it.  There's
also the issue of do we allow the registrants -- do with we allow,
sorry, registrants could make the choice to hold the private keys
themselves, of course, rather than trust their registrar.  Do we insist
that we maintain our current model of registrars still -- sorry,
registrants still sending the keys to the registry through the
registrar.  It introduces another link which potentially doesn't need
to be there.  And could weaken the security by doing that.  If we
change from that then we're changing 9 current model of the way we
work.  But there is the benefit that if we do do that then the keys can
easily follow the registrant in the way -- when the registrant moves
around the registrars.  The other thing we still haven't written there
is what happens if the registrant transfers the domain name to another
registrant, how do we manage the key transfer in that place or how do
we enforce a key rollover or something at that particular point.  And
then finally, what does the registrant do if their keys are compromised
and they hold the keys.  Can they, you know, do we provide emergency
numbers or a way that they can do a quick key rollover, do we insist
that registrars have to provide such a functionality for people.  So
next slide then.

This isn't really technical, though, it might say but there are some
technical considerations.  Currently, many registries limit the number
of times people can change the name servers within a day.  We might all
claim that we do it for fast flux but generally we all do it just so we
don't put too strong a strain on all our resources.  So how often are
we going to let someone change their keys or roll over their keys
within the delegated domains.  If it's going to have a greater
computational impact on us then we might need to restrict that quite a
bit to once a day at the most or something but my biggest fear is
somebody out there who thinks they understand security who wants to
change their keys every couple of minutes.  We, then, have to consider
some other bits and pieces of policy.  What is the minimum or maximum
key size, the minimum because we believe that's secure the maximum
because we believe that's the most we can computationally handle.  What
about signature lifetime?  Do we want to get down to this, but do we
want to say to people if you're going to do this, you can't have too
low a signature lifetime because that will impact on the hole
resolution process or what do we make our own decisions about signature
lifetime.  Are we going to insist that anybody who uses DNSSEC has a
KSK and ZSK configuration, split like that, because you don't strictly
have to do it, people could just use their keys in one way.  And will
we be sitting minimum or maximum number of KSKs, so would we insist
that they have to have two KSKs at any time so that they can effect a
rollover quite quickly because it would make it considerably easier us
being woken up in the middle of the night because they only have one
KSK and their KSK has been compromised.  And this next bit I haven't
really thought through too hard, so some people may point out this
doesn't actually exist, but what do we do about the DNSSEC equivalent
of lame delegations, for example, where we have a DS record and then
are not advertising that key anymore or something like that.  Do we --
do we bother with it or do we not bother with it.  So next slide.

Now, all of these things means that people have got to learn about and
understand about.  And the big question is whose responsibility is it
to teach them.  We are in the slightly unfortunate position, all of us
here, I mean, of being some of the few people who understand it, so we
potentially have a more obligation to be the people who go out to
explain it and teach people how to use it, but then again, that's
another cost for us.  And so do we just educate people, or do we try to
promote it as well as a technology that people should be using for
wider social means.  We didn't have to look quite practically I'm sure
everybody has done it in what resources do registrars need.  One thing
I noticed in previous roles was that we had shown a arbitrary -- not
arbitrary, we had chosen a particular TTL for name server records and
all they're not authoritative they ended up in practice being
authoritative because every registrar copied our TTL and used our TTL
for their authoritative records as well.  And so if we start setting
policies about signature lifetimes and these sort of things and how
we're going to do things, I think there's a very strong chance that the
registrars in our community are going to go, oh, well, they must have
thought about it so we'll just copy and do the same so we need to think
that one through.  And we, like many registries, provide a tool kit for
people to access our services, how much do we need to include DNSSEC
within that.  And the final question is do we just trust any registrar
on implementing DNSSEC or do we need to add DNSSEC specifically into an
accreditation process so that they can, then, put a new badge up saying
we're a DNSSEC accredited registrar, that might make it more difficult
for people to become DNSSEC registrars which potentially defeats the
object.  So next slide, please.

So finally, then, pricing.  Now, we all know this is going to mean an
increase in costs.  There's no way to avoid that.  But we have to
consider how this fits with the policy that we have that many other
people have which is one of cost recovery.  Do we want to charge more,
do we want to split out the costs associated with DNSSEC and charge
more for that.  And I believe at least one other registry does that. 
Do we just want to absorb it and charge the same for it, or do we
actually want to be radical and charge a discount for it?  So that we
can drive up adoption so that people can, you know, take up DNSSEC more
and because it fulfills this wider social gain of securing the Internet
which is really what we're running the registry for, you know, to make
the Internet a better place and keep it free and open.  So last slide. 
That's it.  Any questions at all?

>>STEVE CROCKER:   Oh, yes.

[ Laughter ]

I'll take the privilege of just asking a couple of -- first of all,
this is a excellent really quite excellent set of questions that you
put forth, and conditions, and I really thank you for it.  How many
registrars do you have in your system and maybe another subdivision is
how many of them are ICANN-accredited and how many are not?

>>JAY DALEY:   We have 70 and I don't know how many are ICANN
accredited or not.

>>STEVE CROCKER:   Boy, I just love all of those questions of -- there
was just a lot of dialogue but I'll turn things over to others.

>>MARKUS TRAVAILLE:   Are you going to make this presentation
available to us so we can -- is it going to be on the Web site of --

>>STEVE CROCKER:   Oh, absolutely, this is all completely public, the
transcripts will be on the Web site.  The modulo just are handling
delays.  We'll get the slides up on the Web site too.

>> The slides are actually there now.  They weren't when we started,
but they're there now.

>>MARKUS TRAVAILLE:   I looked at the -- oh, thanks.  Yeah.  Great.   

>>ROSS MUNDY:   Jay, I'm very glad to see that you're maintaining the
possibility from a cost perspective -- I'm sorry, from a charging-the-
customer perspective that it could be a possibly lower than a regular
name.  And I think this is something I'd encourage people to think
about specifically as a means to speed the adoption.

>>STEVE CROCKER:   I see Danny Aerts from dot se who originally
charged for implementation and then stopped charging and I assume he's
now going to tell us that he's going to give a discount, right?

>>DANNY AERTS:  Yes, of course, you're right, but I just want to earn
a bit money to answer the questions also that Jay has mentioned here, I
don't know exactly how much I'm going to earn.  Yes, we started with
charging.  One of the reasons we started to charge in the beginning was
that we were afraid that our registrars were too optimistic and I had
one registrar with about 200,000 domain names and said I'm going to do
this over one night.  So that's why, by charging it, then that means he
had to think twice.  Right now it's for free and, actually, we have the
ambition, and it will be one of your operations, that we will have a
discount in the end because we believe -- let's say, I think there's
quite often a question of why should I do this, there's no business in
it, where is the money in DNSSEC?  There is no money, this is
infrastructure?  This is a part of the obligation of a registry, to my
belief.  So if you think that you're going to make money on it, I don't
think that you will ever implement it because this -- this is mainly
cost, but it's still something I think you should do.

>>STEVE CROCKER:   Thank you.  Yes, sir.  

>>RAED ALFAYEZ:   My name is Raed Alfayez, I'm Saudi Arabia from the
dot sa ccTLD.  I have a question.  I know that implementing or adopting
DNSSEC will have changes in the registry from technical point of view,
but is it a must for a registry to change their regulation in order to
adopt DNSSEC?  Because I have seen lots of things, for example, for
example, changing rollover keys or sorting the keys, these things, does
it have to be in the integration itself, so many changes in the
integration or doesn't it?

>>JAY DALEY:   I think all of these things have to be thought through
and the answers of these are, I suspect, will lead to lots of changes
in the regulation, yes.  Because we -- you can end up with a different
service being provided to registrants if you don't ensure that the
regulation addresses DNSSEC.

>>STEVE CROCKER:   Other questions?

>>ROSS MUNDY:   Let me just point out for folks that are especially in
the ccTLD world that the U.S. Government in particular relative to the
dot gov activity has published a number of documents in a FISMA series
and other U.S. Government gobbledegook type stuff but most accessible
through the NIST Web site and they have had -- they have selected a
number of answers to some of these policy issues or recommendations
that Jay has brought up.  They're example -- all excellent questions,
they all need to be addressed in some manner sometimes the addressing
is that we let users decide a whole bunch of things, sometimes the
addressing is we don't let users or holders of names decide very much,
we tell them so there is a wide spectrum just as, for instance, how
long a particular zone operator makes use of one particular name server
at a particular I.P. address, that's under the control of the zone
operator and the DNSSEC things can be thought of as similar but we do
need to define them in advance what they're going to be but if you want
to take a look what some of the U.S. government's publications are,
they're freely available for anyone to look at and study.

>>STEVE CROCKER:   Good.  Let me add two other points that you pressed
on, Jay, in a number of ways.  One was when somebody wants to transfer
registration, what happens to the key?  And then broadly, does the key
move with them or does the new registrar have to generate the key?  And
this is all under the umbrella of those registrars that are providing
name servers and hence, subsequently signed name servers (sneezing)
excuse me, I have not seen anything that would support transfer of a
private key, and so I'm waiting to be proven wrong, but my
understanding is that there's very strong resistance in the crypto
community to supporting that and correspondingly no development of
tools and products and so forth that would make that sensible except
within very narrow backup of key within the same administrative control
and shared set of devices, as it were.

The other half of that is, well, then, to do the transfer from one
registrar to another, how much complexity and what kind of cooperation
is that and I'll be talking a little bit about that because we have, in
fact, been focusing on that.  The other thing that you touched on was
how many registrars have -- do there have to be to support DNSSEC else
you get locked into one.  This is a point that, actually, was flagged
quite visibly and directly in the RSTEP report that was done in
response to the dot org application for running DNSSEC.  I thought that
was quite, actually, quite a good point.  And I would say, you know,
just my opinion is that any registry should try to make sure that there
is a -- some minimum number of registrars and be in a practiced and
able shape so that you're not stuck with one in that you get a little
bit of practice about all that so I think that's all very helpful.  Any
other questions or discussion?  Yeah.

>>JAY DALEY:   Do you think there's any value in registries
considering insisting that they register support DNSSEC after a period
of time?

>>STEVE CROCKER:   You know, I'll borrow Russ's line that this is,
first and foremost, a decision that each registry can make.  I -- you
know, like most things on the net, things work better if it's an open
choice rather than a -- being compelled.  I would say that there's no
reason to insist that everybody do it because registrars are
competitive, you can move from one registrar to another.  So it doesn't
preclude -- if a customer wants to have his zone signed and his
registrar won't support that, then that is one of the considerations
about possibly choosing alternative registrar, I would say, and that
may be the smoother way to go through the virtual cycle rather than
have a top-down force on it, that's my personal take on that.  Other
thoughts?  Yep.

>> Yes, with regards to the issue of the transfer of the key, I'm not
so sure how the other registries they have implemented DNSSEC for dot
se, but I think maybe you tie the key not to the registrant but to the
domain name in question might be better because whether you transfer
ownership of the domain name or you transfer between the registrar, the
key follows the domain, right, so it becomes a question of if you need
to renew, change the key, then you allow the new registrar to get the
key changed.

>>JAY DALEY:   I think if you insisted that the keys were held in
escrow by the registry, then you could have it follow that.  There
would need to be, you know, the issues about what happens if the key is
being used somewhere else as well, all those sorts of things, but it is
a possibility, I understand Steve's point that some people might think
it's a wrong way to do it.

>>STEVE CROCKER:   Thank you.  Let me move on to the next
presentation, and we have Han -- Han Chuan -- is that right?

>>HAN CHUAN LEE:   That's right.

>>STEVE CROCKER:   -- Lee, on Singapore's implementation of DNSSEC.

>>HAN CHUAN LEE:  Thank you, Steve.  Thank Steve and Jim for the
opportunity to share my experience in the preparation and planning for
implementing DNSSEC.  My name is Han Chuan, my last name is Lee, and
people have been calling me by different versions of my name.  The
technical manager for SGNIC, the ccTLD manager for the dot sg domain
name.  As technical manager for SGNIC, the presentation today will be
not technical, I'll be touching on the policy aspects, so-called
implementation considerations.  

So this is the outline of my presentation.  Just three key things. 
Policy, implementation strategy, and I'll show you some of our proposed
time line for implementation.  Okay.  Sorry.  

As a policy we -- as you see the first bullet point is acronym the IDA. 

IDA is basically the infocom Development Authority of Singapore.  They
are the body in Singapore that looks after the adoption of infocom
technology as well as the regulator of the telecommunication.  

So we actually -- SNIC is wholly owned by IDA, so we brought this
DNSSEC implementation and idea to IDA, and we explored what are the
policy considerations that IDA would be concerned with and actually
would need to comply with.  

So the view that we get from IDA is they would prefer not to use
regulatory means to -- for the implementation of DNSSEC.  IDA has
always gone with this philosophy that market forces should prevail
whenever possible in such adoption of technologies or security
measures, but they are open to having an industry collaboration, if
necessary, a call for collaboration to work on DNSSEC implementation
and grants to the industry or even SGNIC to further the implementation
of DNSSEC.  And so they're not comfortable with the regulatory powers
to maintain that industry must do it, that SGNIC must do it, that the
ISP must do it, that the domain owner must do DNSSEC, so they're going
to leave it to the market to decide.  

One of the key considerations that IDA had was the cost implication of
the implementation to the various stakeholders such as the agencies,
even to us, domain owners and the service providers.  So they wanted us
to come up with a master plan that will address not only the cost
implications, but as well as some of the key issues such as takeup.  We
want to avoid a situation whereby there's great expectations but there
is low realization and the investment and money that's sunk into to get
DNSSEC running is wasted if we launch it and there's only one or two
domains that wants to be signed.  So we want to make sure that in the
whole implementation of things, takeup will be encouraged and there are
activities or there are tasks that is in place to ensure sufficient
takeup.  

And they also want to make sure that we address all the stakeholders'
concerns and their needs.  So it should not be a one-sided kind of
information whereby the registries say, okay, we're going to have
DNSSEC capability, it's going to be turned on.  And if you want it, do
it, right?  So there's no way to see what the registry is going to do
but rather to consider the whole big picture perspective and come up
with a proper master plan, a master strategy, that will make the
implementation a success.

So in terms of the implementation strategy, one of the options that
we're exploring is for the government agencies to take the lead in
implementation.  Now, in Singapore we have this advantage that recently
we launched a program known as the standard operating environment, or
SOE, the projecting the cost so easy, okay, whereby the IT
infrastructure and the management are centralized, okay, which means
that for the domain organizations and the DNS operations and the NS
servers, be it the recursive one and the authoritative one, they are
going to be centrally managed, right, and as of today, we understand
that at least 85% of all the government names, be it dot gov sg or dot
sg, are managed by this agency called the Government Data Center or
under the arm of the government operations.  So for the agencies to
take the lead is actually relatively easier because one implementation,
or one party implemented DNSSEC for the one name will be predicated on
the cost of the other 85% of the government names, and the remaining
15% we were thinking of like -- encourage them to take it up.  So the
regulatory is not looking at issuing a directive to mandate that all
agencies must do it, but this is going to be a road that we can follow.
The task force that we're looking to set up, one will consist entirely
from stakeholders from the government agencies and as well as SGNIC and
this will look solely into how DNSSEC is to be implemented in -- for
government agencies are looking at past practices and eventually where
there really is a need to get this mandated, not mandated, but the
government has just this -- these instruction manuals whereby for any
implementation of IT infrastructure or services, they have certain
guidelines and rules that they follow and it's a consideration whether
or not eventually that needs to be inserted into the instruction
manual.  

The second task force that we're looking at will be on the industry,
get the ISPs, the service providers such as (inaudible) company or the
registrars to be involved in this task force.  We'll be looking more on
the concerns of the general -- the industry, the enterprises, the end
users at large on how DNSSEC is going to affect them and how best to
get this implemented in outreach to them, what are the best practices
that we can count with for these enterprises.  And it's all to make
sure that we have a -- solve an end-to-end combination, that we want to
ensure that we have the support of the ISPs, the support of the service
providers, right, so that it will not be a standalone SGNIC doing it
and the rest of the pictures are missing.  

So one of the tasks by the task force is to sort of look into a
testbed by SGNIC.  It lasts about six months.  And how SGNIC introduces
new products, we usually have a testbed.  So that the end users and the
industry have a view of what DNSSEC is going to be like.  DNSSEC, as
you understand, is relatively new to -- I know it's been out for a
while, but to the industry and to the domain owners, it's still very,
very new to them and very foreign.  So there are bound to be some
skeptics out there.  So we hope that the testbed, you can help address
all of these concerns as far as to let them, so to jump into the water
to get wet first and have a view of how comfortable the water is so
that when we go into commercial, to them it isn't a matter of switching
over to the commercial system and at the same time most of these
implementations actually will be carried out by the technical folks and
they will need to convince their management on the benefits of DNSSEC. 
So it would be a good platform for them to showcase to the management
how DNSSEC is going to benefit the enterprise.  

Also education.  We're also working with IDA, since part of their role
is to look into the development of the infocom skills and manpower in
Singapore.  And one of the security divisions with the IDA carrier
carries out a security seminar on a yearly basis, so we are thinking of
putting in DNSSEC hopefully as the main topic of discussion during the
security seminar sometime early next year and, in fact, anybody who is
interested to come to Singapore, a very lovely island, to come and join
the seminar.  

Okay.  We're also working with training providers to conduct courses
in Singapore on an ongoing basis, one of the first things that we're
looking at is actually to train all of the agencies, engineers and
technical folks to get out the power of DNSSEC first and then to have
this on a regular basis for the industrial application.  

Sorry.  This is the proposed time line that we're looking at.  Right
now we have more or less finalized the master planning so we're going
to get them to show this to IDA and get it endorsed, and we're hoping
this can be completed by July, following which, with the plan out,
we'll be able to start on the formation of the task force, we should
start to do some publicity, so we're also working with IDA on the press
releases and publicity, and we'll have to start to engage all the
stakeholders immediately after and the stakeholders will include other
than the various governmental agencies, so the industry players.  

Next we will also, after engaging the stakeholders -- sorry.  Okay. 
We'll kick start the series of training and education starting at the
end of the year.  And they'll also have us to promote the security
seminar in early next year.  

The testbed I will be starting in September and in February.  We have
already been in discussion with our vendor to -- (saying name) to the
Russian system, as well as to create a separate system for the testbed
so as to minimize the chances of any disruptions to the existing domain
names, right, so we can't totally separate it, and we will definitely
get the registrars to come in for the testbed so they have a view of
how the whole flow, how the whole process is going to be like.  So the
keys will not be sent already to the registry but it will all be done
through the registrars.

With all this we heard that the commercial launch can be started in
April 2010 -- there's a typo there -- with the government agencies
taking the lead.  So we'll have at least 500 names out there that are
already enabled.  And we feel that to the government this is very
important because Singapore has always been advocating economic
resources and have always been a top 20 in terms of (inaudible)
outreach to the public.  And we hope that the benefits that the DNSSEC
can bring are from the (inaudible) services and at the same time
encourage the industry players to, you know, see how successful the
government has done it.  And then they'll come on board together.  And,
hopefully, that you will be 100% implementation in Singapore.  With
that, thank you.  And any questions?

 >>STEVE CROCKER:   That's great.  If you want to give us a corrected
slide, we'll put it up there instead of this one with the 2010 on
there.  Either way.  Any questions?  Discussion?  I think you covered
everything very thoroughly.  Thank you.  Thank you very much.

 >>HAN CHUAN LEE:   Thank you very much.

>>STEVE CROCKER:  Okay.  And now we have from Thailand -- I know that
this effort has been underway for a while.  And who's going to --
where's our speaker? Thank you very much.  Okay.  I'll turn it over to
you, and I'll be happy to control these slides when you say.

>>PENSRI ARUNWATNAMONGKOL:  Yeah, thank you.  I'm Pensri from dot th. 
I'm going to share with you the DNSSEC deployment in dot th.  

So let's start with the next slide, please.

Dot th was created in 1988.  Currently we are running with one
registry, one registrar, and 36 resellers.

Dot th domain only served four types people.  And we require the
document during the registration portion.

So we are running seven categories, subdomains under dot th, for
example, co.th for commercial uses and se.th for academic uses.  And we
do provide Thai IDN under dot th.  Currently we have 9,500 Thai IDN
under dot th.  And we have about 34,000 ASCII domains under the third
level domains.  

Next slide, please.  For the DNSSEC we start our preparation since
December 2006 where we got support from ICANN to organize the first DNS
training in Asia.  After the workshop we consolidated all necessary
information and planned for the deployment.  We select the methodology
and we prepare our new machines.  Then we do the test run.  Earlier of
this year.  And then we have the DNSSEC workshop in February 2009.  And
at this workshop we have a policy session for key stakeholders to
educate them about DNSSEC and how important it is.

Next slide, please.

So after the workshop we have increased our link bandwidth and
prepared for our zone signing.

So we inform our secondary name server about our plan and tell them to
turn on the DNSSEC.  Unfortunately, one of our name servers from UUNET
name server do not support DNSSEC.  So we asked ISC and ISC colleague
offered that name service.  So we have all name servers and we are
running TSIG.  And we signed zone and submit a key to ISC and our key
now listed in IANA and DLV.  

Next slide, please.  So for the operation we are running bind 9.6.0-
P1, and we're using RSA-SHA1 with the 2k bits for key signing key and
1k bits for zone signing key.

We signed dot th in some secondary names, secondary domains like dot
in, dot th and dot co.th.  

For the key rollover period we do one year for the key signing key and
two months for the zone signing key.  

Next slide, please.  This is our zone signing process.  The customer
can send the DNSkey to the registrar.  And the registrar will put that
one in our registry where the zone signer we'll do the zone sign and
publish that signed zone to the registry name server.

Next slide, please.  Thank you.  So this is the timeline we did.  We
did have the public -- that one in February filed a public
announcement.  And then we changed our name server in March.  And we
first signed dot th zone in 30 of March.  And we published our key in
April.  And then we start to communicate with ISP and resellers.  And
the first reseller signed its domain in May, last month.  And this
month they start to sign the customer zone.  

Next slide, please.  Currently, we have only few numbers of signed
domains.  And -- but we get support from the largest reseller and
replan to have a big campaign with our first ISP.  And there is
interest from Thai University, which they also joined a workshop in
February. And they will organize another workshop for university
network in August.  

Next slide, please.  And for future work we plan to do the
registration system that support DNSSEC key input from user or
customer.  And we will do the automate zone signing key rollover.  And
we will do the more larger with ISP reseller, banks, and large
companies as well as government agencies.  So that is all for me now. 
If there are any questions, please.

 >>STEVE CROCKER:   I want to congratulate you, again, on your great
success.

And I know that you have proceeded cautiously and carefully over time
and not sought a lot of publicity and recognition.  But it really is an
excellent accomplishment, and I think we all should congratulate you.

>>PENSRI ARUNWATNAMONGKOL:   Thank you.

 >>STEVE CROCKER:   Any specific questions or comments?

 >>YUNGJIN SUH:   Yungjin.  You said you prepared link bandwidth
increase.  How many times do you increase?  I want to know.  And the
difference between after the -- you applied DNSSEC I want to know the
traffic change.

>>PENSRI ARUNWATNAMONGKOL:  Actually, the previous link bandwidth we
had was only 2 meg, so we increased to 10 megs just in case a lot of
zones signed.  But so far it's not any significant increase.  Thank
you.  

>>STEVE CROCKER:  In future meetings I think there will be an
increasing amount of attention on questions of that nature.  What is
the increase in bandwidth?  What are the increase of -- a lot of
quantitative questions.  

Let me invite you to share that data, whatever you're comfortable
with.  But I think it will be very helpful to others to see what your
experience is in that.  And I know that there will be a lot of
interest.  There's a lot of concern about what the impact is.  And in
most cases the impact is very small.  But hard data, real data will be
more comfortable than just statements like this.

 >>JIM GALVIN:   If I may, there is actually some hard data out there
for dot org.  And OARC has been putting up some graphs.  In fact, they
had put some up at the DNSSEC coalition.  And they were also presented
at the NANOG meeting a couple of weeks ago.  You should expect more
data to be available there.  Some very hard graphs about the amount of
bandwidth and the kinds of queries and what's been going on.  There's
been fairly dramatic change even so far without any signed delegations.
So I would keep an eye out at the OARC Web site to see more.

 >>YUNGJIN SUH:   I wanted to add one.

 >>BARBARA FRASER:   I wanted to add a question sort of related to
that.  Maybe it belongs another place on this session.  But have we
done or has the community done any recent studies on the versions of
the resolvers that are deployed out there?  You know, in the past there
have been a couple -- more than a couple studies that have been done to
actually, you know, survey, if you will, in a technical way, the
versions of bind and so forth that are deployed.  And this has been
done in the past to identify vulnerable versions of it which, from an
altruistic standpoint, the survey starters were trying to improve the
overall security.  My question with the involvement of DNSSEC now it
really is important for us to sort of understand what the resolver
situation is out there, at least from some of the operational issues
and so forth that we are beginning to see.

 >>STEVE CROCKER:   That's a good question.  I'm not familiar with
any.  Is anybody else familiar?  A different question -- yep?

 >>YUNGJIN SUH:   Not a question.  But all ccTLD hosted in our
facility, they just applied -- they signed the zone. And the traffic
was three times increased.  Yeah.

 >>STEVE CROCKER:   So the output from the name server was three
times, as you say?  Okay.  Any other --

 >>RUSS MUNDY:   I was looking for the study that Olaf Kolkman did
while he was at RIPE a few years ago and haven't been able to find the
ready reference.  But it is a RIPE report.  And it is an excellent
analysis looking at a particular set of data.  But it also developed a
model that any authoritative zone operator could use as a basis for
estimating the computing the bandwidth and response time for having a
signed zone versus an unsigned zone.

 >>STEVE CROCKER:   Yeah, I think there's, Russ, he presented a paper
which I think references that data and brings up to date a little bit
at the signed root symposium we had a couple weeks ago.  And that data
will be available.  So the worst case, if I remember, was a factor of
eight from that.  

But there's other aspects that are of interest like what -- how much
fallover to TCP is there and so forth?  Failover, I guess.  

Any other comments?  Okay.  With that, let me move on to Joe Abley
from ICANN's IANA group.

 >>JOE ABLEY:   I guess I'll just lean.  There we go.

Hello again.  It's Joe Abley here from ICANN, from ICANN's DNS group.

Next slide.

So the signing operations that we are building infrastructure support
will take this kind of diagram, which should be fairly familiar.  Zones
edited.  There are hidden masters.  There are name servers which
publish the data.  

To next slide.  The same thing but with a big entertaining box in the
middle that does a bump in the wire signing.  So this is within ICANN's
infrastructure.

Next slide.  The zones that we are intending to sign initially will be
ICANN.org and other ICANN dot something domains.  These will be the
ones we do first.  

The IAB has also requested that ICANN or ICANN or the IANA component
of ICANN proceed with signing the upper top-level domain.  Most
recently, I think, the beginning of June in an email from Olaf Kolkman,
which can be found on the IAB web page.  

The IAB proposed that ICANN prepare a technical proposal for signing
ARPA, which be distributed for community review at the IETF.  And,
although the precise workflow for how ARPA will be signed remains to be
clarified, we hope that we can make some rapid progress on this.  Next
slide.  

We have some work underway to automate the back-end processes for
maintaining the IP6.ARPA in-ADDR.ARPA zones.  Once we talked further
with the RIRs about how that should happen, we hope to sign those two. 
There are other dot zones of ARPA --  URN.ARPA, URI.ARPA, and IRIS.ARPA
which we also hope to sign.  IANA.org we hope to sign and others as
appropriate.  So there are some infrastructure zones here and some TLDs
in a nonregistry sense, somewhat different to the other TLDs that have
been discussed here and some ICANN use zones.  ICANN, of course, is
very interested in participating as an end user as -- and contributing
to the public knowledge of the process from that perspective.  Next
slide.

So the infrastructure that we intend to use, those who saw my brief
update in Mexico or those that downloaded it from the web page will
find the description of the find of redundancy and physical security
that we were deploying in support of signing the root zone.  The plans
for signing the root have since crystallized in a different direction. 
The infrastructure that we have begun to deploy for signing the root as
if we were -- as if ICANN was the organization operating the ZSK is now
being used for signing the other zones.  I won't repeat that here.  I
appreciate this has been a long session already.  Next slide.

So, as far as status goes, the secure containers which are built to
order have been bought.  They have been built.  And one of them has
been delivered.  Our site, our facility at Equinox in LA3, the facility
buildout is complete.   We have multi-layer physical security there,
including a fully-enclosed cage, including a mesh ceiling to contain
the secure container.  The secure container is installed.  It's
powered.  Servers are installed.  Network components are installed.  So
the basic building blocks of the infrastructure are all ready now. 
Next slide.

We still have work to do on the key management and operational
procedures for signing those zones.  Even though, arguably, these zones
are lower profile than the root, we still intend to do a good job at
this.  And we also intend that all this documentation eventually be
made public in case it's of use to other use to other people going
through similar exercises.  

We also continue to plan to build a second redundant facility for
signing these things.  And, as I mentioned before, some of these zones,
there are some process and procedural workflow with other organizations
that we need to work through.  And, potentially, our plans will be
refined as they undergo technical review and procedural review by other
people.  

One thing that I forgot to put on this slide is the details of the
software that we're using.  The immediate plan is to build on our
experience in running the IANA DNSSEC test bed and to use the software
which has been running successfully for two years and with which we
have corresponding operational experience and to use that as our
initial set of software for signing these zones that I mentioned here. 
We're also tracking the development of open DNSSEC quite with some
interest.  And, once we feel that that software reaches sufficient
level of maturity for our various stakeholders to be comfortable with
us, once we've done an appropriate amount of testing, we imagine a
transition to that platform.  

I think that's the last slide.  But just -- timeline, there we go.

So we're moving fairly swiftly here.  We hope to have something that
is running in some sense live, which can form the basis of a public
test by the Stockholm IETF.  That's not to say that we expect to finish
the work by then.  That's the point at which we expect to have
something that people can look at in combination with reviewing the
technical procedures and other documentation that we circulate for
review by the rest of the community.  So it will probably change after
that.  But certainly by the IETF there should be some name servers that
can be queried.

Next slide.  And that is it.  Yep.

 >>STEVE CROCKER:   Thank you.  Questions?  You've bowled them over. 
Keep going.  That's good.

 >>JAY DALEY:   With open DNSSEC, the work that you're doing on the
key management and operational procedures, are you feeding that into
DNSSEC, open DNSSEC to help show the way forward for that work?  

>>JOE ABLEY:  The work that's been done on the IR test bed so far has
been done mainly by Rick.  Rick Lamb.  If Rick has comments on that,
perhaps Roy has perspectives from the open DNSSEC side.

 >>RICK LAMB:   I'll just answer that.  Early on we supplied some of
the base code dealing with HSMs and all and continue to looking forward
to work with Jake and others to help with the open DNSSEC effort.

 >>ROY ARENDS:   And from the open DNSSEC perspective, we absolutely
welcome any help we can get in referring our codes, looking at
procedures we use.  Basically, looking at the way we use our HSMs,
looking at security faults and stuff like that.  So thank you.

 >>JAY DALEY:   I was thinking more of the key signing policy level.

You know, the encoding of that information, whether that was something
you also are involved with rather than just the HSM work.

 >>ROY ARENDS:   I'm not speaking here for IANA or ICANN of course. 
But within open DNSSEC we are doing something that's called KASP. 
That's the key and signing policy.  When I refer to -- so this is what
I mean with security faults.  KASP allows you to simply configure when
rollovers need to be done what kind of keys are using, basically, what
kind of security policy do you want?  And have opened the DNSSEC
basically do the rest, the elements of the products we call KASP.

 >>JAY DALEY:   Maybe to the point, my question is whether IANA,
having done all the work to understand what kind of policies they want
and needed in the test bed, have fed that into open DNSSEC to develop --
drive the development of KASP to make sure it then fits with your needs
and ways of doing things?

 >>RICK LAMB:   We haven't done that yet.

 >>STEVE CROCKER:   Good.  Thank you.  Okay.  Let me move on.  I'm
going to give a brief presentation on some work that we're doing
looking at the transfer process between registrars.  So this follows up
very much on the questions that Jay put forth in his presentation.  We
observed that a lot of registrars provide name service to their
customers.  And so we looked at the question of what happens when a
customer wants to transition -- transfer his registration from one
registrar to another and the registrars are providing the name service
and those -- that name service is providing a signed -- the registrar
signed the zone.  And so it's got to be a transition of a signed zone. 
And the -- the full measure of what we wanted to accomplish is that
that transfer should be able to take place with no breach in the
availability of the zones, so it doesn't go dark, and no breach in the
authentication.  So we wanted not to have it go dark and not go through
a period of it being unsigned or the verification wouldn't work.  We
looked to see if that was, in fact, feasible or if there was any
significant problems.  We did encounter a rather interesting
phenomenon, which is the -- and I'm a little bit out of sequence here. 
But I'll just get right to the heart of it that a lot of resolvers will
continue to fetch data after it's been -- after the TTL has expired,
they'll go back to the same place that they've been getting the data
rather than to the parent.  The effect is that if you're going to try
to transfer name service from one place to another, there is no
apparent way to do it smoothly without the cooperation of the losing
registrar.  Now that's a somewhat contentious statement and needs to be
socialized and explored a bit further.  We made a presentation to the
registrar constituency yesterday and that stimulated some very
interesting discussion.  But that's where the nub of the issues are. 
The other part of the equation, which is what's on this slide here, is
there's a conceptual choice about whether the private key is
transferred or whether a new key has to be generated by the gaining
registrar.  As I said earlier, so far as I know, there is no support
whatsoever from a policy or from technology that's available to move
private keys around since there's a very, very strong ethic, if you
will, that private keys should be kept closely held and not exposed or
moved.  So that means that the alternative is a key rollover done in
conjunction with a registration transfer.  And it's a matter of getting
all those pieces exactly right.  In our preliminary thinking it appears
that there might be a degree of cooperation required among registrars
that has not been common.  And so there will be some question as to
whether the registrars would cooperate in that.  In line with the
previous discussion about whether all the registrars have to do this or
only the ones that sort of want to, one could tie this in participation
in DNSSEC and make it part of what you have to do if you want to be a
registrar that supports DNSSEC.  And the ones that don't don't have to
do anything, but then they're also not supporting DNSSEC.  That's at
least one line of thinking.

Here's a diagram about all that. And here's some details from a
presentation at an OARC workshop a couple weeks ago.  And I really kind
of want to leave it here at that level of detail, although I'm happy to
discuss any questions.  But I think this is sort of the right level of
discussion at this point in time.  Much more work will follow on this. 
So be very detailed timing diagrams and specific protocols and so
forth.  Any questions?  Wow.  I have a sense that people are thinking a
lot more about lunch than -- so with that, let me move to the last
presentation, that's what you wanted to hear.  That there really is a
last presentation.  Russ Mundy here will present on trust anchor
repositories.

 >>RUSS MUNDY:   Thanks, Steve.  Moving right along, I tried to
structure this presentation so that it could be three minutes to 30
minutes and anything in between.  So I'm going to shoot more for the 5-
to 6-minute time frame.  So, if there are questions -- maybe we can
even get people out a little bit ahead of time.

So DNSSEC trust anchors are an essential part of DNSSEC functioning
because the users of information, which is what this is all about is
the consumers of DNS information have to have a way to start their
validation process.  And the trust anchor is the place that it starts
from.  And so your choice of how you get your trust anchors is very
important in terms of the over all security that's provided by DNSSEC. 
And here's an illustration on the left side you'll see a completely
signed hierarchy where all the green nodes and lines indicate that
every zone is signed.  That's truly the ideal that those folks that
have been involved in DNSSEC old and new, I think, in every case would
like to see.  The reality is it's not going to happen for a long time. 
On the right-hand side, you'll see intermittent, if you will, sort of
mixed spots where some zones are green, some zones are black.  The
green ones meaning they're signed; the black ones meaning they're not
signed.  And, if the user that's represented by the notebook in the
middle there wants to be able to validate every one of those zones
that's signed, they have to somehow acquire the trust anchors for each
of those what we sometimes call island of trust.  

And so what is a trust anchor repository, and how would they be used? 
So really, what -- what are they?  Their idea of a repository is it's a
collection of trust anchors so that a validator can go to one place, a
repository and get a whole batch of trust anchors.  And how would they
be used?  There's two general views on this.  And one is that it's used
for filling out the hierarchy, as shown from that first illustration. 
And the second one being that certain communities of interest might
choose to set up some specialized use of DNSSEC.  And communities do
what communities want to do.  And they make use of technology in
sometimes unexpected ways.  But you could do the same kind of thing
with a TAR.  I'm not going to talk about that any further.  It's not
really directly related to DNSSEC deployment.  So that's sort of a
secondary use.  But that's another one.  Next.

So on the right-hand side is another illustration of the validator
getting their trust anchors from one spot.  So the high-level pros and
cons really boil down to the holes in the hierarchy filling argument is
why you'd want to do this and it's a method -- if you do have and make
use of TARs, it's a method that any validator can make use of so that
when a new signed zone appears anywhere in the hierarchy, they can make
use of it.  The general cons -- and there's more pros and more cons but
these are sort of the top levels -- is that by doing a TAR, you
actually may be detracting both technical expertise, planning and
resources from doing the real DNSSEC deployment, as some people say. 
And another negative about it is that it lowers the motivation for
parent zones to get signed when zones underneath of it get signed. 
There's a long list of both pros and cons behind it that I won't go
into here, but these are kind of the top levels.  So we've had a lot of
venues for discussing TARs.  In some ways I think it's really been
driven by the DNSSEC deployment working group that Steve and I cochair
and we've had discussions in many other venues and there's a list of
documentations that are output from this at the end so a lot of places
for discussing it and a lot of material resulting.  Next.

So what's the current status?  Well, there's not a brought consensus
about even what is a DNSSEC TAR or what is not a DNSSEC TAR.  There's
also not a total consensus of any sort about whether or not DNSSEC TARs
are needed and this is the consensus across the community.  However, we
do have -- yeah, next, please.  We do have real examples of things that
can be considered TARs today.  So clearly, some people see them as very
important activities and there are a number of activities that are
making use of them.  I have enumerated them here.  The top one is the
ICANN ITAR, which has certain characteristics, is operated by ICANN. 
Another one is the ISC DLV.  And there are two other different types
and not everyone in the community who's thought about TARs would
consider all of these activities TARs but by some definition of TARs
here's four examples that exist.

So this lack of consensus what we think is developing at least to an
extent is the -- that there needs to be a better coalesce sense of what
it takes to constitute a TAR or not be a TAR.  And so in our -- in the
DNSSEC deployment working group activities we're undertaking to develop
a couple of -- one or two documents that will give essentially a best
current practice view of what a TAR is, how it works, what would the
security aspects be and generally one would be considered a fairly
strong extensive security level and the other would be more at a lower
level, almost of the -- akin to the opportunistic encryption work some
of which has come out of the ITF.  Next.

So here's a couple of pages of pointers to TAR material, I won't go
into any of them but they're on the slides so you can check out the
URLs.  Next, next.

So kind of the closing thoughts that I'd like to put forth here is
that folks that have spent some time thinking about TARs very often
come up with a strong idea of what they believe a TAR is or is not and
when they engage in discussions with other people they often find that
others have a very different view of what constitutes a TAR.  Which has
proven to be difficult because we've had a hard time even engaging in
consistent conversations because people may be using the same words and
meaning different things.  So the details are important.  Next, please.

So we solicit input.  We don't have a whole lot of time left today but
we certainly can take a few questions or comments here.  We have about
four minutes left.  And -- but I urge everybody that's interested in
this to join in and engage in the discussion going on in the DNSSEC
deployment working group and it's all -- all the -- most of the
archives and most of the -- all the mail list information is available
through that Web site there.  So with that, I will stop this part and
ask if there are any questions, comments.  This has got to be a record,
to have a presentation on TARs and have no questions or comments.  I
think it's wonderful myself.

>>JIANKANG YAO:   I want to know what's the difference between a TAR
and an ITAR, key difference.

>>STEVE CROCKER:   Barbara, this is yours.

>>BARBARA ROSEMAN:   Okay, well, the ITAR that ICANN is managing is
for TLDs only, and it is meant to be an interim trust anchor repository
to ultimately go away when the root has been signed and everybody's
comfortable with that -- with that model.  There are other stars in
place some of which are grabbing keys from the ITAR, others of which
are accepting keys from a number of different sources both at the top
level and at the second level and below.  So the unique thing about the
ITAR is we use the same processes for putting data into the ITAR that
we do for putting data into the root zone except it's all on the IANA
side, there's no involvement of any other parties.

>>ROSS MUNDY:   So, again, as I tried to point out in the
presentation, the differences are really in the details.  And the
details are incredibly important when it comes to having discussion
about what a TAR may -- what may be considered a TAR or what may not be
considered a TAR and different types of TARs.  So it's a very lengthy
discussion, too long to get into it here but I'd happy to have a
discussion with you afterwards if you feel like.

>>JIANKANG YAO:   So this will be kept there forever so how long will
be exists, the TAR?

>>ROSS MUNDY:   Barbara, let me -- the ITAR, I think you already
addressed it, but it's -- the ITAR is intended to only be in place
until the signed root is fully operational, established and well under
way.  Other TARs may have another life-span.  So each star established
may have a different life stand depending on the details for that
particular TAR.

>>STEVE CROCKER:   Any other questions?  No.  All right.  This brings
this quite lengthy and very packed, full agenda to a close.  Let me
thank you all for attending and for participating.  This has been a
pretty interactive session.  We're going to have another session like
this in Seoul.  My expectation is that we'll move into another level of
depth related to implementation experience and deployment experience
and move some of the focus even on to the validators and resolvers. 
Don't be bashful about making suggestions about what to present or what
you'd like to see presented.  This is, I think, been helpful to
everybody and comments and criticisms are hereby solicited.

So with that, let me bring this to a close.  Any last words, Russ?

>>ROSS MUNDY:   Well, I'd like to thank everybody for their
participation.  I think we had great interaction with lots of folks
today and this is just incredibly helpful to us.  And let me just, one
more time, urge folks to join in the DNSSEC deployment activities. 
It's ongoing and it's the -- there's a lot of other forums but that's
one that has a lot of things going on in this space so dnssec-
deployment.org is the Web site to start from and get the mail list and
other activities from there.  Thank you, everybody.