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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 15 Jan 2002 10:17:27 -0800

> we did.  the call ended 2002.01.07, a week ago.  there was no 
> consensus.
> we're trying not to close the door, but rather encourage discussion to
> try and find if there is a reasonable, high-quality, position 
> over which
> we can reach consensus.  sad to say, none has yet emerged.

Perhaps then we should consider the points that have been raised 
so far in the debate and which do not seem to be in dispute.

1) The additional cost of deploying DNSSEC.

	X = The number of signed delegations
	Z = The size of the zone
	S = The size of a signature

2535                (2Z + 2X) S
2535 + DS           (Z + 2X) S
2535 + DS + OPTIN   2X S

S = 1024 bits for RSA, 320 bits for DSA

1a) RSA is to be preferred as a signature algorithm.
	Although the signature size is larger for RSA the verification
time is very much faster (order of magnitude according to EKR).

1b) The size of the .com, .net, .org zones is a total of 30 million names

1a) The cost of deployment in .com, .net, .org

If X is small:

2535               Increases data volume by factor of 6
2535+DS            Increases data volume by factor of 3.5 
2535+DS+OPTIN      Has negligible impact on data size.

2) The DS modification is a necessary change to the specification 
that is not backwards compatible.

3) OPT-IN does not weaken the security model for its intended scope
of use. Anyone can apply for an unregistered domain name, ergo a 
record insertion attack is not a threat.

4) OPT-IN may be used in inappropriate circumstances in which the
record insertion attack is a threat.

There is however no consensus on the following point:

5) Whether the group should attempt to prohibit 'inappropriate'
use of OPTIN.

5a) Whether this is desirable
	Might a military zone 

5b) Whether this is actually possible

There are objections of the following form:

6) There might exist some objection to OPT-IN that the objector
has not yet thought of but might do so in the future.

7) The cost of deploying DNSSEC _should_ be made prohibitively
high for operators of large zones.

8) If the cost of deployment is too high the cost should be met
by increasing the registration fees rather than modifying the 
protocol.

[While I have great sympathy with this position, I doubt that
ICANN would find it persuasive]

		Phill

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

---

From: [email-masked]
Date: Wed, 16 Jan 2002 13:14:23 +1100

> record insertion attack is not a threat.

	OPT-IN also allows for records (delegations) to appear to be
	*deleted* from a zone.  This is a weaker security model.

	People for the most part don't care about data being added
	to COM.  The do however care very much about data disappearing
	from COM.  Just look at all the bad press from the stuff ups 
	in the past.

	What you are saying to all the existing domain holders under
	COM is: "If you want your delegation to be protected from
	DoS attacks you have to submit a DS record."

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Wed, 16 Jan 2002 09:24:13 -0500 (EST)

> 	DoS attacks you have to submit a DS record."

This statement is true with or without opt-in.  If your delegation isn't
signed, the spoofer can just attack the query to your name servers,
instead of the query to the .com name servers.

---

From: Mike Schiraldi <[email-masked]>
Date: Wed, 16 Jan 2002 11:55:36 -0500

> instead of the query to the .com name servers.

Additionally, making a domain look like it doesn't exist essentially amounts
to a denial of service attack*. If a DoS attack is one's goal, and one has
the ability to manipulate your DNS packets, no amount of crypto or other
security measures can prevent it.

*There may be more subtle attacks based on making an unsecure domain look
like it doesn't exist, but as you said, this can be done even without opt-in
by attacking the child zone. And again, this can't be done with a secure
zone.

-- 
Mike Schiraldi
VeriSign Applied Research