wrt joao damas' DLV talk on wednesday

    what is the security policy that isc plans to use over the
    content of the isc dlv registry? and how will the dvl trust
    key roll-over and revocation be handled?
if the above can not be very clearly answered (by isc?), then this
proposal is techno-political hubris at best.

yes, or an interesting proof-of-concept that can be taken-up and
completed by someone else.

actually, i suspect that the issues of dlv are exactly those of
iana root signing, key management and tld signature policy. and
hence dlv is hoisted on the same petard it attempts to avoid, and
then devolves to a simple power play of isc vs iana with neither
having a good answer to the real technical and security issues.

randy

Randy,

actually, i suspect that the issues of dlv are exactly those of
iana root signing, key management and tld signature policy.

Nope. Oh sure, from a technical perspective, the problems are pretty much the same, but I think they are solvable (if not in a way that will please everyone). However, one of the major layer-9 or above issues having to do with signing the root is "who is going to sign the root", which translates to "who owns the root". The answer, from a political perspective, isn't as obvious as one might wish.

When you push down a layer in the DNS hierarchy, then the layer-9 or above issue becomes _much_ clearer and easier to solve. ccTLD admins and folks like PIR, Verisign, Neustar, etc., have clear and unambiguous authority over their zones (not getting into the argument of whether they should have clear and unambiguous authority) and thus, there is no question who should sign those zones (how is a mere implementation detail).

The problem is, if you push down a layer, you have to figure out how to get the appropriate keying information into the caching server's "trusted-key" (or moral equivalent) statement. I personally think some sort of automated non-DNS out-of-band mechanism would be better than recreating the "who gets to sign X" problem, but there are lots of annoying details to deal with.

and
hence dlv is hoisted on the same petard it attempts to avoid, and
then devolves to a simple power play of isc vs iana with neither
having a good answer to the real technical and security issues.

Can you have a power play when at least one party doesn't play?

IANA's role is really easy: people tell us what to do, we try to do it. When somebody tells IANA how to deal with root signing, key management, and tld signature policy, we do what is necessary to implement what is asked of us. Until then, I'm a bemused bystander...

Rgds,
-drc

I'd like to hear about DLV. For example, Randy Bush asked (twice) the
following:

> my question was a bit simpler. what is the security policy that isc
> plans to use over the content of the isc dlv registry? and how will
> the dvl trust key roll-over and revocation be handled?

I would also like to understand the security policy, and to hear how DLV
at ISC will handle key roll-over and revocation.

since joao is probably still sleeping-off the time shift from san jose to
madrid, i'll chime in here. the last plan i saw was the same as the last
draft i heard about for what any other "important" zone would do with a
key that has to be hard coded in a lot of places: allocate more than one
KSK and an infinite lifetime. use this KSK offline (only), to generate
ZSK's with short lifetimes that are in turn used online to sign the zone.

many are those argue that DNSSEC-bis, having failed to address key-rollover,
is unimplementable. DNSSEC-ter may or may not come about (depending on the
contining faith and patience of those who funded DNSSEC and DNSSEC-bis) in
order to (a) prevent zone-walking, (b) allow for unsecured subdelegations,
and (c) automate key-rollover. (that's NSEC3 and TAKREM in a nutshell.)

on the other hand i believe that DNSSEC-bis is good enough to solve some
real world problems, and that the thing that makes it unimplementable is
merely its dependence on cooperation between US-DoC, ICANN, and VeriSign
around the myriad issues touched on by the "sign the root zone" work item.
that's why ISC is helping (under contract to VeriSign and Nominet) with
NSEC3 and stands ready to help with automated trust anchor work as well--
these are important problems.

if hand-edited trust anchors backed by infinite-lifetime offline KSK's are
unacceptable to you, then you are already not a candidate for DNSSEC-bis
and you're going to be waiting for DNSSEC-ter. so, no complaints about
the fact that DLV uses the only thing DNSSEC-bis specifies in that area,
unless you have a proposal for automated rollover that's as easy to
implement as DLV was, and IPR-unencumbered, in which case, send it over!

> as providing a tld key registry is tantamount to emulating the root key
> responsibilities of the iana, potential users should be rather concerned.

"tantamount" is an unruly word, it accuses without specification. in any
case anyone who is concerned about DLV should seek alternatives, such as:

  1. figure out why the root zone isn't signed and fix whatever it is.

  2. design your own version of DLV (as sam weiler has done, long before
     ISC's although i didn't learn this until later), publish it, and
     urge adoption (find someone to run a DLV registry, implement the
     validator side, and so on.)

  3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code
     for the validator side, start your own DLV registry.

  4. go to IETF and say "i think something DLV should be a standard but
     i don't like ISC's, so let's make an RFC together."

and i forgot to mention:

   5. forget about DNSSEC until all these problems are solved by others.

whichever (or whatever else related) you want to do, you can count on ISC's
support. just don't count on ISC's inaction; ISC isn't adept at inaction.

that URL again is <http://www.isc.org/ops/dlv/&gt;\.

drc@virtualized.org (David Conrad) writes:

Can you have a power play when at least one party doesn't play?

what i find fascinating by the whole "why don't you and him fight?" angle
being played out here is that there is *no* trusted entity for this. drc,
can you check with your corporate masters to find out whether ICANN, ISOC,
ITU, NRO, and the other alphabet-soup denizens of your choice could somehow
do a joint venture around DLV? it seems to me that if we dilute the stew
with enough disparite international unaligned interests, we'll eventually
reach a point where the result appears so dilute as to be powerless and
therefore trustworthy, but still barely potent enough to operate a DLV
zone.

Unless I misunderstood the issues are not some-kind of power-play but
that in order to use DNSSEC right now you need to be within the zone/TLD that itself is using DNSSEC and these are almost non-existent right now with zone maintainers unwilling to take necessary financial and other risks associated with upgrading to fully support DNSSEC. So DLV offers potential for individual domain owners to start using DNSSEC without waiting for the registry operator of their domain's TLD or SLD.

This seems good to me and I'm happy ISC as non-profit organization
is taking the initiative as I don't want the same situation as was
with domains and certificates at the end of 1990s where profit-driven companies were acting as virtual monopoly in domain business.

since joao is probably still sleeping-off the time shift from san jose to
madrid, i'll chime in here. the last plan i saw was the same as the last
draft i heard about for what any other "important" zone would do with a
key that has to be hard coded in a lot of places: allocate more than one
KSK and an infinite lifetime. use this KSK offline (only), to generate
ZSK's with short lifetimes that are in turn used online to sign the zone.

At NANOG 37, possibly after you had left the room, Randy actually
asked if we were writing a document describing ISC's operational
guidelines and policies for the dlv zone. All those things DRC recently
said no one has told him to do yet. It's in that context I think that
he asks these questions now.

I got the idea Randy was looking for info like appears in the BCP
that describes root server operations requirements, except as applies
to our DLV zone (and probably not an IETF document).

So, how many boxes have the private keys? What barriers lock them away?
How many people have access to the raw keys? How many authoritative
servers give out dlv.isc.org and where do they sit in the network and
on the globe? Do you pre-publish or double-sign (or triple-sign (or
quintuple-sign (or ...)))?

I have no idea if such a thing exists or plans to exist, or what might
appear inside it.

> 1. figure out why the root zone isn't signed and fix whatever it is.
> 2. design your own version of DLV (as sam weiler has done, long before
> 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code
> 4. go to IETF and say "i think something DLV should be a standard but
  5. forget about DNSSEC until all these problems are solved by others.

Even if I choose not to do any of those 5 things and adopt ISC's DLV
registry, I probably would want some basis to compare ISC's DLV
registry with Acme's DLV registry.

Having a basis to compare ourselves with...an imagined ideal of
ourselves...is a bit of an intellectual excercise, but it does set
the bar for future work in similar operations, such as signing TLDs
and the root zone (wether it is IANA who is asked to do it or not).

And it helps people decide if they want to throw in or wait it out
for someone with stronger practices (or deploy a DLV with stronger
practices).

I personally think Randy's request (or my imagined version of same)
would be good reading, if someone could be found who had both the
time and knowledge to write it, and if doing so wouldn't be construed
as giving away the keys to the castle.

I got the idea Randy was looking for info like appears in the BCP
that describes root server operations requirements, except as applies
to our DLV zone (and probably not an IETF document).

actually, i think it most important that a proposed dlv service
make very clear its security policy and process in vetting the
correctness of the data it serves, i.e. the trust anchors for
dependent zones.

once one can have confidence in the correctness of the data
served, one might then become inclined to worry about the
reliability of the service :-).

randy

actually, i think it most important that a proposed dlv service
make very clear its security policy and process in vetting the
correctness of the data it serves, i.e. the trust anchors for
dependent zones.

Oh, you're asking specifically for more detail than is on our
web page, then ('Registering your zone key in the DLV tree').

You mentioned that this would have relevance to future practices
should the root be signed, and I can't for the life of me see how.

I think this is an artificial problem that arises only for ISC since
we're out of the delegation loop (except where we can authenticate
registries and receive trust anchors from them).

Do you imagine that, if IANA/ICANN/USDOT/someone were told to
implement a policy to sign the root, that they would have trouble
identifying the owners of the TLD's reliably?

If so, wouldn't this problem already exist today in the information
already present in the root zone?

Hi,

Do you imagine that, if IANA/ICANN/USDOT/someone were told to
implement a policy to sign the root, that they would have trouble
identifying the owners of the TLD's reliably?

Yes. And it isn't a question of signing the root -- that just makes it more ... fun. It is a generic authentication problem that crops up anytime there is any change to the root. Fortunately, the root community is relatively small and well defined and IANA has evolved processes that, while sub-optimal, do generally work.

If so, wouldn't this problem already exist today in the information
already present in the root zone?

Yes. However, I believe you all are proposing to remove the "relatively small and well defined" component that helps IANA deal with the issue on a daily basis. A hard problem.

Rgds,
-drc

I think this is an artificial problem that arises only for ISC
since we're out of the delegation loop (except where we can
authenticate registries and receive trust anchors from them).

if other non-delegators run dlv services, they will have the same
issues. and if you are a delegator, why play dlv as you can
directly sign?

Do you imagine that, if IANA/ICANN/USDOT/someone were told to
implement a policy to sign the root, that they would have trouble
identifying the owners of the TLD's reliably?

how they validated that the keys they sign are correct would be an
issue, for sure. but we have some idea of the iana's relationship
with the tld zone holders, though, like many things, that could
certainly be improved.

the isc web page now says

    Before it is accepted into the dlv.isc.org zone, ISC will
    perform checks to ensure the keys are being used in the
    requested zone, that the persons making the request are who
    they claim to be and that they are authorised by the domain
    holder to request the inclusion of the keys in the zone.

    This check will require an in-person meeting with authorised
    ISC staff to verify documentation.

so, there will be strange travel costs incurred, but we have no
idea what actual checks will be done. when charles mussisi flies
from kampala to redwood city, will he be expected to have brougt
the zone key with him on cdrom or something, and you'll check his
passport against the iana cctld registry and then accept the key?

and, when the iana redelates the UG zone, how will you know this
and stop handing out a bogus key?

If so, wouldn't this problem already exist today in the information
already present in the root zone?

yep. and iana goes through some non-trivial exercises to validate
that they are delegating 'correctly' as defined by 1591 and other
documents. and those of us in the tld game are aware of them in
some detail, irrespective of our opinion of them. luckily, they do
not require people to pay airlines.

all i am asking is that isc publish *how* it will validate the
correctness of the zone trust keys they sign and provide under
their proposed dlv service. e.g., how do you propose to check that
the cctld, e.g. NG or UG, for which your proposed dlv service might
yield a key is indeed the real NG or UG zone key?

randy

the isc web page now says

    Before it is accepted into the dlv.isc.org zone, ISC will
    perform checks to ensure the keys are being used in the
    requested zone, that the persons making the request are who
    they claim to be and that they are authorised by the domain
    holder to request the inclusion of the keys in the zone.

    This check will require an in-person meeting with authorised
    ISC staff to verify documentation.

so, there will be strange travel costs incurred, but we have no
idea what actual checks will be done. when charles mussisi flies
from kampala to redwood city, will he be expected to have brougt
the zone key with him on cdrom or something, and you'll check his
passport against the iana cctld registry and then accept the key?

I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does.

It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary.

In the case of Uganda, by way of example, I've met Charles in person several times, and I'm sure we will do so again. I remain on ISC's books as an unpaid volunteer. If I can help Charles and ISC on some mutually-agreeable project I would of course be happy to.

The social tendrils of ISC run longer and deeper than many people realise. Perhaps this is one of the things that makes ISC a good organisation to anchor projects like DLV.

and, when the iana redelates the UG zone, how will you know this
and stop handing out a bogus key?

I can't answer that question. My expertise in this area is less about the crypto, and more about the beer :slight_smile:

Joe

I don't profess to speak for ISC here, but it may be worth noting
that ISC staff continue to spend a lot of time travelling to operator
meetings, workshops, root server installations and RIR and ICANN
meetings. Outreach and community participation is one of the core
things that ISC does.

It's not unreasonable to think that for a lot of zone operators
(ccTLD or otherwise), the mountain will eventually come to Mohammed,
and travel by the zone operator won't be necessary.

can you say "does not scale?" or how about "works poorly when a
zone is transferred?"

i think there is no question that you and isc mean well. but we've
entered the the twisty passages of security.

randy

Indeed.

With the current trust policy, it seems to me that DLV is a bootstrap mechanism intended to promote bottom-up pressure for DNSSEC deployment, and to give people a chance to get to grips with things like key rollover and zone signing.

It's a frog dressed up as a chicken which is being rolled out because people are fed up waiting for an egg.

In that context, perhaps it doesn't need to scale very far.

Joe

With the current trust policy, it seems to me that DLV is a
bootstrap mechanism intended to promote bottom-up pressure for
DNSSEC deployment, and to give people a chance to get to grips
with things like key rollover and zone signing.

well, unlike ipv6 marketing efforts, at least it does not create
an unrecoverable mess in routing.

It's a frog dressed up as a chicken which is being rolled out
because people are fed up waiting for an egg.

In that context, perhaps it doesn't need to scale very far.

perhaps the bottom line is whether it makes us more vulnerable.
while an incorrectly secured zone is arguably no worse than one
which is not secured, it seems to create a focus for attack.

but what leaves me wondering is why this is all so difficult.
why can isc not simply say "we plan to vet zones as follows:.
and we plan to manage maintenance of key rollover as follows:
etc.?"

randy

but what leaves me wondering is why this is all so difficult.

Possibly because many people find writing formal security policies, which I think is what we're really talking about here, to be a dry and unpleasant experience, much less fun that code-hacking or packet-analyzing or whatever else you can find to do instead.

why can isc not simply say "we plan to vet zones as follows:.
and we plan to manage maintenance of key rollover as follows:
etc.?"

Would it help if I volunteered to talk to folks and help write something up? I mean, if there's some other issue that is preventing ISC from nailing this down, then that's one thing. But if it's just a case of "never seems to bubble up to the top of the stack", then maybe a little outside assistance can do the trick.

Besides, now that the semester's over, I need something besides just firing off resumes (gotta fill that summer time, and not completely lose touch with the Real World!) to keep myself entertained.

You may flame when ready, Gridley.

...

can you say "does not scale?" ...

...

I think ISC very clearly already said that. They do not WANT it to
scale. They _WANT_ DNSSEC to succeed and take over. This is a
bootstrap mechanism to get DNSSEC rolling.

can you say "does not scale?" or how about "works poorly when a
zone is transferred?"

There are two ways to look at "scaling". Scaling in volume and scaling across generations. DLV definitely does not scale across generations with such a person-to-person protocol backing it up. But if it's just a bootstrap mechanism, then I think it's acceptable.

As far as volume scale, DLV puts more work onto whomever configures DLV repository data in resolvers. A DLV per TLD might lower the work for the TLD, and possibly remove the need to develop NSEC3 and opt-in. (As DLV only lists the DNSSEC'd zones.)

i think there is no question that you and isc mean well. but we've
entered the the twisty passages of security.

DLV at least lets those who are able and willing to take the risk to gain first hand experience. If the ISC DLV runs for 5 years without an incident, even with the non-scalable approach as documented, it'll be seen as a winner. The longer it runs without incident, the more trustworthy it'll (appear to) be, right up until the point that it no longer scales. If there's an incident, then it won't be trusted but we will probably learn from the experience. Hopefully the lesson will come cheap.

> can you say "does not scale?"

Indeed.

this is why we're trying to sign up some registrars, starting with alice's,
who can send us blocks of keys based on their pre-existing trust
relationships.

if other non-delegators run dlv services, they will have the same
issues.

Absolutely.

and if you are a delegator, why play dlv as you can
directly sign?

I think Paul answered this question (it's because of the way
DNSSEC-bis proves non-existence).

I basically can't answer your other questions. I don't know the
answers to most of them and don't want to guess at the others.

And as for IANA applicability, I guess I'll have to give up and
defer to you and DRC. It still sounds wonky to me that you would
operate the root's authentication chain out-of-band like a DLV
registry when in-band seems so much more useful and reliable.

But clearly I don't know enough about the root's (scary) problems.

when charles mussisi flies
from kampala to redwood city,

I think our staff in Europe are closer to Kampala than 950 Charter,
and I assume at least one of them would be authorized, and I assume
that there are some events somewhere that both Mr. Mussisi and some
authorized member of our staff are likely to both attend.

But if you would like to imagine for a moment that we actually require
people to meet us in a faraday cage embedded 30 feet under the Arctic
ice in an undisclosed location - just take a metal detector with you
and knock on the ice when you think you've found us - then which of
Paul's list of 5 other options would you prefer? Or is there a 6th?

How soon can you start?

That's an important open question in this dialogue.

... and alice has been working on deploying the .org DNSSEC testbed for 6 months now. Thus far my experence with deploying DNSSEC is: its just hard, not fun and for a lack of a better word... it SUCKS.

In the last 6months since we deployed it, not one sole has clicked on the [now broken] _SECURE DOMAIN_ link to enable .ORG dnssec capabilities.

I know we are a tiny registrar but none of our clients thought it important enough to even try clicking on the _SECURE DOMAIN_ link. So, even DLV is going to take a tremendous marketing effort to get folks to differentiate it from LOCK_DOMAIN which merely prevents the domain from being updated or transfered.

DLV is a huge task so be supportive because it will probably fail just like DNSSEC is ...but we might just learn something.

-rick

Paul Vixie wrote: