Subject: DS and Opt-in - a proposal

From: Olafur Gudmundsson <[email-masked]>, Randy Bush <[email-masked]>
Date: Fri, 21 Dec 2001 15:15:50 -0800

This is a request for comments.  Members of the working group who disagree
with these recommendations, please send technical comments on the mailing
list ASAP.  Similarly technical points in support we might have missed
should also be sent to the list.

There has been discussion among interested parties on the issue of DS [0]
and Opt-in [1] adoption in DNS.  A small group has discussed the issues in
on a conference call and has identified following issues:
 o DS and OPT-in both break backwards compatibility with RFC 2535.
 o DS increases protocol complexity but reduces operational effort.
 o OPT-in limits authenticated denial of secured names while at the same
   time potentially saving significant operating costs for large delegating
   zones.
 o Due to key management scaling issues, deploying RFC 2535 without DS will
   severely limit the usability of DNSSEC.
 o The cost of incompatible changes increases steeply with time.  Currently,
   there is minimal deployment of RFC 2535 signed zones, so there is minimal
   use of secure revolvers, so the impact is lowest now.
 o Delegations in DNS have problems when it comes to securing, NS set is on
   both sides and child signs.
 o The value of authenticated denial is not clear, for some it is important,
   for others it is only a nice but sometimes expensive property.

The discussion concluded that the deployment of DS was critical, and worried
that a decision not to adopt Opt-in could pose problems in deployment.  Thus
we propose the following:
 o DS and Opt-in proposals both be adopted and
 o RFC 2535 backwards compatibility NOT be retained. (flag day!)
	
In parallel to getting slightly revised OPT-in and DS documents published as
Proposed Standards, the following activities should take place:
 o Implementation(s) of name servers and revolver(s) that support DS and
   Opt-in must be made available as soon as possible.
 o The rewrite of RFC 2535 should be resumed and completed no later than
   June 2002.

Time-line 
  - Opt-in and DS go for WG last call February 1
  - Opt-in and DS go for IETF last call February 15
  - RFC 2535bis-00 draft March 1
  - RFC 2535bis-xx WG last call March 15

List of people participating in the discussion group 
  Roy Arends
  Steve Bellovin (regrets)
  Randy Bush
  Olafur Gudmundsson
  Edward Lewis
  Mark Kosters
  Paul Vixie
  Brian Wellington

This beings a two week last call on this proposal, to end 2002.01.01.

Thanks,
  Olafur Gudmundsson and Randy Bush
  dnsext co-chairs

---

[0] - draft-ietf-dnsext-delegation-signer-04.txt
[1] - draft-ietf-dnsext-dnssec-opt-in-01.txt

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Fri, 21 Dec 2001 22:46:22 -0500

>This beings a two week last call on this proposal, to end 2002.01.01.

Before anyone jumps up and down this the date is 2002/Jan/07

         Olafur

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 27 Dec 2001 10:14:46 +0100

On Fri, 21 Dec 2001 15:15:50 -0800
Olafur Gudmundsson <[email-masked]>, Randy Bush <[email-masked]> wrote:

One detail.
 
>    for others it is only a nice but sometimes expensive property.

I would like to know if there will be a new version of the OPT-in
draft that allows opt-in only over delegation records? ( I am still
afraid that 'security status' on a level more granular than zone level
will make troubleshooting of verifiers a difficult exercise. Reducing
the usability of OPT-in to delegations only might help to keep
deployment limited to only the largest (g|c)TLDs. I understood
'delegation only' was considdered for a new version of the draft.)

--Olaf

P.S. I love the idea to have DNSSEC in a workable state by summer.

---

From: Brian Wellington <[email-masked]>
Date: Thu, 27 Dec 2001 22:25:59 -0800 (PST)

> 'delegation only' was considdered for a new version of the draft.)

This was suggested on the conference call, but was not generally agreed
upon.  One reasons is that it makes verifiers more complicated, since they
not only need to verify the NXT records, but then additionally verify that
the record is a delegation (granted, this is not too hard).  Also, the
restriction of opt-in to large delegating zones can be seen as a
disadvantage.

If the goal is to restrict the use of opt-in, this would do it, but I
don't know if that's the goal.

Brian

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 28 Dec 2001 09:33:35 +0100

On Thu, 27 Dec 2001 22:25:59 -0800 (PST)

> don't know if that's the goal.

I am for restricting the use of opt-in; if we allow the use of OPT-IN in
end nodes of the DNS tree I fear that DNSSEC has lost is usefulness for
protecting the DNS infrastructure. 

The reason is that securing the DNS as a whole is IMHO the whole
purpose of the game. If we allow administrators to sign only a few RRs
in a zone (which we do with non restricted OPT-IN) then we might end
up in a situation where only the records that might be useful in a PKI
context are signed.

If we want to secure the DNS then security should not be optional on
RR level because then the path of least resistance will be chosen and
we end up with only a few RRs signed in each zone.

Second argument is, again, from the view of the resolver
administrator. Who would set up a verifying cache if the cost of
trouble shooting is to high. Troubleshooting costs would be high if
authenticated denial of existence is lost at end node zones. Mind you
that the first use of DNSSEC would be securing large caches. (That is
one of of our major goals within the DISI project, getting zones
secured and getting ISPs to verify them).

I realize these are not a purely technical argument but zone and
resolver operators are humans. Humans tend to tale the path of least
resistance. 

As you know I am not pro OPT-IN but I understand it's need. As argued
long ago I think that OPT-IN should be used only in a few (g|t)LD
zones and as a transition mechanism, any other use would not help
securing the DNS. Designing the protocol in such a way that it can
only be used for delegating zones and as a transition mechanism is I
thing a Good Thing (TM).

Pheww... Happy  new year all.

--Olaf

--Olaf

---------------------------------------------------------------------
  Olaf M. Kolkman      |  RIPE NCC DISI Project     
     -----------       |      ---------------	     ----------------
  RIPE NCC             |  Phone:   +31 20 535 4444   | 
  Singel 258           |  Fax:     +31 20 535 4445   | 
  1016 AB Amsterdam    |  http://www.ripe.net/disi   | 
  The Netherlands      |  [email-masked]          |

---

From: bert hubert <[email-masked]>
Date: Fri, 28 Dec 2001 07:50:44 +0100

> P.S. I love the idea to have DNSSEC in a workable state by summer.

I seem to keep hammering this point - have clientside people been involved
yet? The vast majority of DNS lookups right now are A queries, and most of
those come from the browser.

So far the admirable enthousiasm for DNSSEC has come from specs writers but
before finalizing, it is absolutely vital to get the browser people
involved. DNSSEC is going nowhere if they aren't going to use it! And they
may not use it if DNSSEC is unable to offer semantics that their users are
going to be interested in.

Getting Mozilla involved ought to be easy.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc

---

From: Roy Arends <[email-masked]>
Date: Fri, 28 Dec 2001 12:06:10 +0100 (CET)

> 'delegation only' was considdered for a new version of the draft.)

We are not talking about authenticated [denial of] existence in general,
only about authenticated [denial of] existence of unsecured names.

Imagine going into a tourist office (.city), the only authoritative
place in town to get the authenticatable, verifiable information from.

I ask for the address of "hall.city".

The "hall.city" delegation is not secured.

The clerk is going to tell me "it exist".......

That's not really helpful now, is it. I can't go anywhere else to look it
up (it's the only authoritative place in town) and I'm left with a
statement that "hall.city exists"

(I knew it existed, that's why I came in that office for the address in
the first place)

I call that "false sense of security".

Oh, and "we" are not giving anything up, "we" give a choice to the
domain holder.

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 28 Dec 2001 12:59:23 +0100 (CET)

On Fri, 28 Dec 2001, Olaf M. Kolkman wrote:

> On Fri, 28 Dec 2001 11:14:01 +0100 (CET)
> Roy Arends <[email-masked]> wrote:
>
> >
> > Restricting the use would be possible, but is, in reality, useless. If I
> > could not leave a single name (end node) unsigned, I might delegate it
> > away as an unsigned zone.
> >
>
> That is indeed possible, just as it is possible in RFC 2535. But, it
> is clear what the status of the delegated zone is. All records are
> verifiable unsecure.

That status is also very clear with opt-in. It signals unambiguously if a
record is signed or not.

> If we want to secure the infrastructure we should build a protocol
> that goes for maximum effect. My argument is that OPT-IN in
> non-delegating zones will help in building a PKI but not secure the
> infrastructure.

Only signing records will help to secure the infrastructure, regardless of
Opt-in or 2535.

> Administrators of large caches will not turn verification on if only a
> few records in a few zones are signed;  It is to expensive to
> troubleshoot and there is little to gain.  I think we are far from
> having the applications or their host os-es doing their own
> verification, so if administrators do not turn their caches into
> verifying caches then DNSSEC has failed to secure the infrastructure.

I hear so many stories about the future of DNSSEC, I'll refrain from
making statements. I'm not worried though.

> The other interest group, users that want to use the DNS as a PKI, will
> not suffer from OPT-IN.

Okay.

> I can live with OPT-IN if it is designed to be a transition mechanism
> for g|tLDs. If it is designed to be used throughout the whole tree
> DNSSEC will loose.

I'm afraid that it is very difficult (if not impossible) to restrict the
domain holder like that.

Restricting opt-in to delegations only is merely a psychological
restriction. The domain holder can legally "route" around that restriction
easily.

Roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 28 Dec 2001 11:57:46 +0100

The other interest group, users that want to use the DNS as a PKI, will
not suffer from OPT-IN. The verification will be done by the specially
designed applications. They are not interested in fully signed zones,
they just want to get to that one RR and need to verify it.

--Olaf

---

From: Greg Hudson <[email-masked]>
Date: 28 Dec 2001 09:25:26 -0500

> those come from the browser.

In the Unix world, at least, the applications shouldn't have to get
involved, just the recursive resolver (named, traditionally) and to some
extent the stub resolver in libc.  The application may be interested in
knowing whether a DNS record was signed, but even if it doesn't care, a
signed record can't be subverted by DNS spoofing.

I don't know enough about the non-Unix world (which, admittedly, is
where most of the users are) to comment on it.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Dec 2001 09:09:02 -0800

> From: "Olaf M. Kolkman" <[email-masked]>
> ...
> ...

>From a zone administrator's point of view, given the tools I know exist
today and which I expect will be created within the first few years, it
is _vastly_ less resistive to sign the whole zone than to sign just parts
of it related to PKI.

I agree with your goals.  Let's secure the infrastructure.  However, the
way the bits are falling out is that restricting opt-in to delegations 
would *add* complexity, and only for administrative/nontechnical reasons.
Even though DNSSEC doesn't demonstrate much in the way of good protocol
design, there remains a principle of good protocol design to "put in only
what you need."  Your proposal would be an addition, and it isn't needed
since zone administrators *can* secure the whole infrastructure without it.

---

From: Randy Bush <[email-masked]>
Date: Fri, 28 Dec 2001 09:47:49 -0800

> I'm afraid that it is very difficult (if not impossible) to restrict the

yup.  create a feature and 95% of the uses of it will be unnecessary and
stoopid.  so only create features when they're *really* needed and well-
scoped.  though i am still personally a bit uncomfortable with opt-in for
reasons related to this, the likely harm of unneeded uses seems low, and
the verisign gang whine soooo pathetically :-).

randy

---

From: Roy Arends <[email-masked]>
Date: Fri, 28 Dec 2001 11:14:01 +0100 (CET)

Roy

---

From: Mike Schiraldi <[email-masked]>
Date: Fri, 28 Dec 2001 13:51:52 -0500

> statement that "hall.city exists"

To put it another way, in an opt-in zone, a middleman can take a domain name
that does not exist and make it appear that an unsecure domain exists at
that name.

This is not considered a big deal at the TLD level, because even under RFC
2535, a middleman could do that with the following four steps:

1. Go to www.nsi.com
2. Type the nonexistant domain into the textbox and press enter
3. Pay $35
4. Point your new unsecure domain anywhere you'd like

However, this is a concern at other levels. For example, if ibm.com was
opt-in, a middleman could make it look like an unsecure delegation called
corporate.ibm.com existed and thereby make it look like his computers were
part of IBM's network. But that's the security tradeoff you make when your
zone is opt-in.

I think that end user zones SHOULD NOT be opt-in, but whether they MUST NOT
be is up for debate. Which is less of a headache? So far, i'm not sure.

-- 
Mike Schiraldi
VeriSign Applied Research

---

From: bert hubert <[email-masked]>
Date: Sat, 29 Dec 2001 08:45:31 +0100

> extent the stub resolver in libc.  The application may be interested in

You must live in a parallel universe from mine. The application developer
has needs. If DNSSEC is unable to meet, or worse, not interested in those
needs, s/he will ignore it. It is not a unix question.

> where most of the users are) to comment on it.

There is no difference. Right now DNSSEC is purely academic with some
laboratory experiments. Some fairy may come along and suddenly make all user
applications DNSSEC aware, but don't count on it. It's not that you write
the RFC and suddenly people start implementing it.

Just saying 'it is transparent from an applications' point of view' does not
cut it. 

Interesting to note is that I'm told that IE has its own resolver, separate
from the regular windows one.

Regards,

bert

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sat, 29 Dec 2001 20:13:33 +0100

Folks,

    though i am still personally a bit uncomfortable with opt-in for
    reasons related to this, the likely harm of unneeded uses seems low, and
    the verisign gang whine soooo pathetically :-).

What me personally disturbs about this discussion is that there is
so little technical or operational content in the whining. Apart
from the somewhat dogmatic statement ``my XX-million customers will
complain'', I have been told that ``Yes, we can sign but the current
technology cannot provide the footprint we need to service a secure
com. zone''. (Statements like these were made in Salt Lake City).
Up to now, I haven't seeen any numbers supporting this statement.

I would really like to see some numbers, hard facts or at least
some data to support why an opt-in is needed.

	jaap

PS. Why do I want to see this? About two years ago (around that
	time anyway) arguments were floating around that it would
	be impossible to do DNSSEC because signing big zones was
	close to be impossible.  These arguments turned about to
	be hearsay.  Yes, signing big zones is hard but doable.

	Now convince me that an opt-in DNSSEC solution is really 
	needed.

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Dec 2001 11:58:30 -0800

> some data to support why an opt-in is needed.

we certainly have enough hacks on this beast already.

randy

---

From: Greg Hudson <[email-masked]>
Date: 30 Dec 2001 00:57:50 -0500

> needs, s/he will ignore it. It is not a unix question.

What needs?

Your initial message said "DNSSEC is going nowhere if they [browsers]
aren't going to use it!"  I was arguing that DNSSEC is useful even if
browsers stay the same as the are, at least in the Unix world.  If:

  * DNSSEC is deployed at the root,
  * the recursive resolver is DNSSEC-aware and knows the root's key,
  * com, amazon.com, and www.amazon.com are signed, and
  * the path from the stub resolver to the recursive resolver isn't easy
    to attack (because they're on the same machine, the path is behind a
    firewall which the attacker can't get behind, or the path is
    protected by TSIG)

then it becomes prohibitively difficult to spoof the address of
www.amazon.com, even if the browser is completely ignorant of DNSSEC. 
That's a win over the current situation, where it is relatively easy to
spoof that address (especially if you can watch the query, but in many
cases even if you can't).

> the RFC and suddenly people start implementing it.

The only reason I can think of why most user applications would need to
be DNSSEC-aware is to convey to the user whether a domain is signed or
not.  Since most users don't understand what that means, I don't think
that's the most important part of DNSSEC.

> Just saying 'it is transparent from an applications' point of view' does not

Why not?

> from the regular windows one.

Its own stub resolver or its own recursive resolver?  If the latter
(which I somewhat doubt; it wouldn't work so well with firewalls), then
like any other recursive resolver, that would need to implement DNSSEC
in order to benefit.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 Dec 2001 08:21:49 -0800

> cases even if you can't).

<AOL>ME TOO!</AOL>

---

From: bert hubert <[email-masked]>
Date: Mon, 31 Dec 2001 11:28:14 +0100

> > browsers stay the same as the are, at least in the Unix world.  If:
(...)
> <AOL>ME TOO!</AOL>

Aha. So we don't care about the implementors and clients of DNSSEC because
we've all figured it out on our own. That is not a sound engineering
principle. Oh well. Good luck in your ivory tower.

Regards,

bert

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 Dec 2001 09:06:31 -0800

> principle. Oh well. Good luck in your ivory tower.

to paraphrase mr. bush, "that ain't what was said."

dnssec does not require any api changes or client changes in order to make
a large number of dns lookups more secure.  if zone servers and full resolvers
("authoritative and recursive nameservers") implement it, and if stub 
resolvers ("clients") use TSIG or some other secure last-mile channel (doors?
IPSec?) to reach their local recursive nameservers, then "security" will go
"up."

of course, a dnssec-aware api that would allow for dnssec-aware clients would
also help explore ways to make things more secure, and we should do it.

but we do not have to have a new api or change any clients before DNSSEC can
be at least initially effective.

so, welcome to my ivory tower.  (you were already inside.)

---

From: Roy Arends <[email-masked]>
Date: Mon, 31 Dec 2001 17:54:30 +0100 (CET)

On Sat, 29 Dec 2001, Jaap Akkerhuis wrote:

> so little technical or operational content in the whining.

I was glad that in SLC we've put the layer 8/9 arguements aside and could
finally focus on the protocol itself. Anyway:

Optin improves the protocol because:

  o it gives a choice between 2535 or opt-in. (the domain-holder can make
    that choice)
  o opt-in gets rid of unwanted/unnecessary crypto. (the domain-holder
    decides what is necessary and what not).

Conclusion, a smaller zone to manage, a smaller zone to service, a smaller
zone to handle. And still, the signed data will be as secure as with 2535,
the unsigned data will be as secure as with 1035. There is no ambiguity
anymore as in "this unsigned data might be spoofed[1035], but
exists[2535]". Everyone gets what they want. If one is "a bit
uncomfortable with" or is "personally disturbed" by opt-in, sign the zone
2535-style. You have that choice :-)

> Apart from the somewhat dogmatic statement ``my XX-million customers
> will complain'', I have been told that ``Yes, we can sign but the
> current technology cannot provide the footprint we need to service a
> secure com. zone''. (Statements like these were made in Salt Lake
> City). Up to now, I haven't seeen any numbers supporting this
> statement.

I find it very reasonable to accept/believe that serving a zone 2535 style
is more costly then serving an opt-in style zone.

> 	Now convince me that an opt-in DNSSEC solution is really

Should large investments in operational hardware be made for a protocol
requirement that is unwanted by some, just because we can ? Since a
domain-holder will be confronted with the extra costs, without having a
choice, it will be calculated through to the sub-domain-holder. If that is
going to happen, we're even further away from deployment.

Now convince me that an opt-in DNSSEC solution really will hurt,
security-wise.