Subject: RE: DS and Opt-in - a proposal

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 10 Jan 2002 17:05:57 -0800

I have yet to see a technical argument of any kind against Opt-in.

To assist the group I enclose my summary of this thread below. I
really do not see the technical opposition that Randy appears to 
believe exists.

At SLC I heard plenty of political arguments of the form 'we do not 
want to support this community' or even 'we want to deliberately
disenfranchise this community'. If it is the view of the group that
they do not want to support .com, .net and .org I would like the
group to explicitly state that that is their position.

I take issue with Ted's analysis. There is another possibility. If
the group decides to design a DNS security specification that cannot
be supported by a significant community then the result will be 
divergence. That is a bad thing in the DNS system. 

Remember however that it takes two to diverge. In fact I don't 
believe that divergence is a likely outcome. Instead what I believe
is a more likely outcome is that the IESG asks why the DNSEXT group
is disputing a protocol modification which nobody is seriously
disputing is necessary if DNSSEC is to be depolyable in the large 
domains so that the 30 million odd names registered in them can
use the protcol. The group is told to fix the problem before the
planned rewrite of 2535 goes forward.

The way to make standards progress rapidly in standards processes
is to fix them promptly when problems are identified. I have never
seen a standards process accelerated by ignoring design flaws.

To answer the issues in the thread:

Ted's analysis essentially argues that because full implementation
of DNS sec is unlikely the Opt in proposal reduces the probaility
of full implementation occurring (!) I do not understand this argument.
Perhaps there is a mistype and a negative was dropped somewhere.

The technical case for Opt-in is that it very substantially reduces
the cost of deployment of DNSsec in the large domains. The security
model supported by Opt-in provides exactly the same security assurances
with the single exception that in an opt-in zone an attacker may 
insert a record for an unregistered zone. This 'risk' does not constitute
a 'threat' in the large domains because any party can register a domain
in .com, .net or .org by means of a credit card.

The issues raised against were that a change in the spec would break 
backwards compatibility in the limited sense that a resolver that does
not support Opt-in would be unable to make use of an opt-in secured
zone. This does not seem to be much of an argument when the alternative 
is not to have the zone secured at all. Opt in is an optional spec,
the only consequence of this risk is that the security considerations
section should provide adequate warning that the issue must be considered.

Olaf's contributions were as follows:

>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.

This is not a valid criticism. If a zone is large enough that opt-in
becomes necessary it is unlikely that it is being managed using standard
tools in any case. The proponents of opt-in are not expecting to rely
on the community at large to implement the signing component. 

>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? 

And later:

>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.

Again this is not a technical argument, it is social. It is trumped 
by the argument that there will be practically no use of DNS sec if
it cannot be deployed in the large zones.

>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.

>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. 

OPT-IN is definitely not suitable for use throughout the whole tree.
The insertion of the DNS record 12ry24f1872trw287yt1247t.com does not
constitute a security threat. The insertion of shop.ibm.com does.
This is however no more than a security consideration.

Steve Bellovin made a proposal concerning Bloom filters, however there
was only one response and it appears to be somewhat late in the game to
start a completely new track (as Steve himself suggests might be the 
case).

Jaap asked for some hard numbers that demonstrate the need for opt-in.

It has been demonstrated that without OPT-IN the data volumes would 
increase by a significant factor (10). It is simply naive to believe that
such a change would be accomodated by any operator of a critical 
infrastructure unless there was an overwhelming justification.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 10, 2002 4:50 AM
> To: Randy Bush; Olafur Gudmundsson
> Cc: namedroppers
> Subject: Re: DS and Opt-in - a proposal
> 
> 
> [Quoting Randy Bush, on Jan  9,  8:41, in "Re: DS and Opt-in -  ..."]
> 
> >   o there seems to be a very clear consensus for DS.  in 
> fact, there were
> >     no negative technical comments.
> 
> Agree.
> 
> >   o there does not seem to be a consensus for Opt-In.  there was
> >     considerable discussion pro and con, with technical 
> considerations
> >     in both directions.
> > 
> > if someone has NEW technical arguments to present for or 
> against either
> > proposal, please do so now.  N_E_W arguments.
> 
> N_E_W arguments, at least new technical arguments, are probably
> difficult to produce, I think they have been beaten to death
> and are pretty clear for most of us.
> 
> What has not been discussed enough, IMHO, is what we want to
> accomplish with DNSSEC, and once we answer that question, the
> technical arguments about Opt-In fall into place easily.
> 
> I'll try to take a shot at it. I see four paths to go forward:
> 
> 1. Forget DNSSEC in its current shape.
> 2. Strive for full implementation, i.e. the goal is to get
>    most of the DNS tree secured over time.
> 3. Go for course grain security, i.e. some or more large secureds
>    branches side by side with large unsecured branches, and
>    divided by clearly defined borders.
> 4. Go for fine grain security, i.e. some or more secured RRs within
>    a further unsecured DNS-tree.
> 
> ad 1. This will happen when we do not go forward, it's the 
> easy way :-)
> 
> ad 2. This is not realistic to expect to happen soon.
> 
> ad 3. Course grain security will lead to secured safehavens,
>       garded by the major DNS forwarders/cachers. Some users
>       may also check themselves, but many others will probably
>       just trust their ISPs DNS forwarders/cachers. This way,
>       it will be difficult for scriptkiddies to produce major
>       spoofs in the safehavens, which is a major gain.
> 
> ad 4. Fine grain security makes it possible to have scattered
>       secured RRs, this is more easily implementaed than 3, and
>       it solves many problems for instance for the IPSEC people,
>       and may open some interesting business opportunities.
>       People who want these scattered secured RRs to be certified
>       will check them themselves, others will probably want an
>       answer (with possible outdated sig) more dearly than a
>       certified answer, so chances are big that most major DNS
>       forwarders/cachers will not bother checking the few
>       scattered secured RRs.
> 
> Now, lets see how Opt-In fits in:
> 1. Does not matter.
> 2. Chances are slim we ever get here without Opt-In, chances
>    are virtually zero we get here when we start with Opt-In.
> 3. Opt-In does not fit into this scheme.
> 4. Opt-In makes this possible, but there are probably more
>    easy ways to accomplish the same (like an alternative PKI
>    outside DNS, or DNSSEC without auth. denial).
> 
> -- ted
> 
> 
> 
> 
> to unsubscribe send a message to 
> [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
>

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 11 Jan 2002 14:03:19 +0100 (MET)

> Jaap asked for some hard numbers that demonstrate the need for opt-in.

but has not been presented any. none. please provide us with facts why you
cannot sign and serve the gtlds you are operating if opt-in is not
deployed.

	jakob

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