Subject: Re: What are the opt-in issues

From: [email-masked] (Ted Lindgreen)
Date: Mon, 10 Jun 2002 09:48:50 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

[Quoting "Phillip Hallam-Baker", on Jun 10,  4:06, in "Re: What are the opt ..."]

> The Typo attack is simply a sub class of an attack that was identified in
> the original security analysis. Any party can apply for an unregistered
> domain name in a TLD at any time, the authentication criteria applied by
> registrars do not include verification that the applicant of the domain name
> has provided a bona fide address on which process can be served.

Phillip,

You are confusing a Registry issue (a security problem due to lack
of proper administration) with a security hole inside the protocol
itself. The fact that the former exists at some Registries does not
mean we don't need to care about the latter.

-- ted

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Phill" <[email-masked]>
Date: Mon, 10 Jun 2002 09:24:57 -0400

>mean we don't need to care about the latter.

No I am performing a security analysis of a system as opposed to a
single component. Analysis of the system is almost always the preferred
choice for an application protocol.

I am fully aware of the fact that a security analysis that is performed
in one context may fail in another. For example 4 digit account PINs
works for ATM cards but has major failure modes when used on the
Internet. Knowing the appropriate security analysis to apply is my job.
That is why I frequently advise against blindly reusing protocols in
applications that are beyond the context of the original security
context.

The decision to fully sign or OPTIN sign a zone is acknowledged to have
security implications. You should not use OPTIN unless you have
determined that either an insertion attack is not an issue (as is the
case for the registries) or the cost of fully signing the domain is
greater than the probability of an insertion attack multiplied by the
cost of the damage caused.

The term 'security hole' is not appropriate in this instance. A security
hole is by definition an error in the design. A limitation of the
applicability of a protocol is not a security hole if that limitation is
clearly stated.

		Phill