Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal)

From: [email-masked] (Ted Lindgreen)
Date: Tue, 15 Jan 2002 10:21:39 +0100

[Quoting [email-masked], on Jan 15,  6:33, in "Re: OPT-IN at delega ..."]

> 	I think it is a reasonable compromise.

Somehow, I have the feeling that from the trio
             reasonable
	     compromise
	     security
2 words can be combined, but not all 3.

For quite some time I've heard "Opt-in is mostly harmless",
and the Olaf/Olafur proposal seems even more harmless. But,
it's the "mostly" and "even more" that keeps nagging.

In other words, I concur with Vixie:

[Quoting Paul Vixie, on Jan 15,  9:26, in "Re: OPT-IN at delega ..."]

> rather than compromise between two invalid positions using an encoding
> which is undetectably violatable, i think we ought to reverse the sense
> of the poll.  opt-in has been proposed.  can anyone oppose it on grounds
> which are (a) technical and (b) not yet shown to be invalid?

Of course, when someone in the crowd can just pinpoint a weak spot,
then it's over immediately.

But if not, I'd still like us to seriously investigate:

   Does it really improve the protocol?

In that decision, I think that security issues should weight a
little more than conveniance issues.

If the answer is yes, we adopt it, of not we forget it.

-- ted

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 15 Jan 2002 11:54:28 -0500 (EST)

> 2 words can be combined, but not all 3.

This (and the following paragraph) are complete FUD.  If opt-in does
something harmful to DNSSEC, say what it is.  Don't merely repeat that
you're nervous about it.

We know exactly what opt-in-at-delegations-only gives up: for domains
which choose to use it, it gives up authenticated denial of insecure
delegations, and allows the insertion of insecure delegations where no
authoritative data exists in the domain.

Because of that, we expect that opt-in would only be used in domains where
insertion of insecure delegations would be harmless, such as the .com
domain.  (There is no motivation to use it in a regular domain full of
mostly authoritative data.)

>    Does it really improve the protocol?

Yes, it does.  It allows a large domain full of insecure delegations to
deploy the protocol without wasting a lot of resources on protecting those
insecure delegations.

I'm not personally very excited about that because I don't run a large
domain, but I have yet to see an even vaguely convincing reason why we
shouldn't do it for the sake of people who do run such domains.

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Jan 2002 09:44:37 -0800

> Because of that, we expect that opt-in would only be used in domains
> where insertion of insecure delegations would be harmless, such as the
> .com domain.

i suspect that, if we could really ensure that this was the case, many
people would feel more comfortable.  fear of the mass of mis-guided zone
admins may underly much of people's discomfort.

randy

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jan 2002 10:04:44 -0800

> admins may underly much of people's discomfort.

but, but, that way lies madness.  most zone owners don't have multiple NS's
on different networks, either.  but even if it were possible to modify the
protocol to require this, we WOULD NOT DO IT.

why not?  because it's up to zone owners to decide how to serve their zones.

protecting other people from their own stupidity, against their
expressed will, is "paternalism".  that's not our business here.

arguments of the form "dns will not be as secure as it could be if opt-in
is adopted" are rife with the logical fallacy of "begging the question" and
are completely subjective/judgemental.  that's not our business here, either.

(will dns be more secure if more zones are signed?  will opt-in make it 
easier for more zones to be signed?  and so on.  let's just not go there.)

"who is still debating this?"

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jan 2002 10:20:38 -0800

> then it's over immediately.

subject to the vagueries of the word "pinpoint", that sounds true.
(but getting this crowd to agree that something has been pinpointed
seems unlikely, so i think we'd better not count on this happening.)

> little more than conveniance issues.

i do not consider those two issue-types to be separable or distinct.

if it is too inconvenient, some zones won't be signed, which will lower
the overall impact of DNSSEC even though it won't change the security
level enjoyed by producers and consumers of zones which ARE signed.

and so on.

> If the answer is yes, we adopt it, of not we forget it.

i don't think that's a workable approach.  rather, we have some very strong
arguments on the table from some zone-operators who say they need a specific
feature (opt-in) for their own zones.  and we have some other very strong
arguments on the table from some resolver-operators who say they do not
want (some or all, depending) zone-operator anywhere to have the opt-in
feature.

neither side has shown any flexibility.

as protocol designers, we can't decide this issue by looking at the quality
of the arguments, since they aren't arguments about the same issue.  one
side is arguing from zone operability, the other from resolver operability.

so we have to ignore the arguments and decide which basis is more relevant.
should the inflexible resolver-operators dictate the presence or absence of
this feature, or shall the inflexible zone-operators dictate it?

remember, both sides have effective workarounds.  resolver operators will be
able to tell whether the data they are seeing is secure or not.  zone
operators can wait for moore's law to catch up a little.  either way, the
inflexible arguments themselves are all going to be moot by the time we
get it deployed.

"whose data is it, anyway?"

---

From: Greg Hudson <[email-masked]>
Date: Tue, 15 Jan 2002 16:42:28 -0500 (EST)

> admins may underly much of people's discomfort.

Well, if opt-in is only allowed for insecure delegations, then there
shouldn't be much call to implement it on the server side in major
implementations like BIND.  (I'm assuming that Verisign is planning on
using some kind of custom code, not BIND, to sign the .com zone, yes?)  If
it isn't widely implemented on the server side, there isn't much danger of
it being misused.

(Of course, opt-in has to be implemented widely on the client side or
it won't do what it's supposed to do.)