Subject: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 27 Apr 2003 07:18:34 -0700

Summary
	In favor	12
	Abstain	 7
	Opposed	 2

I have counted as abstain all the folk who said they did not think OptIn a
good idea but would let it go through for the sake of consensus. These were
6 people all told. The other abstention being someone who did not actually
appear to have made a concrete statement.

Folk may want to check I recorded their statement correctly. Unfortunately I
could not find a web archive that would let me link the statements to the
actual posts.

Unsurprisingly support for OptIn comes from the large registries and Paul
Vixie. Nobody appears to have changed their mind during the discussion.
There is definitely consensus on the proposition that it is high time the
debate closed so we can get on with the next bit.

In Favor
--------

Paul Vixie
	as an individual, i support this.

Roy Arends
	I support opt-in.

Matt Larson
	I support Opt-In.

Mark Kosters
	I support Opt-In.

Olaf Kolkman
	Although I would advise against its use in all other cases but the
huge
zones out there, I do support the draft.

Ted Lemon
	I support opt-in.   We've been playing around with DNSSEC for a long

time, and we will still be playing with it (or have abandoned it) ten 
years from now if we don't adopt opt-in.

Phillip Hallam-Baker
	In favor

Scott Rose
	I support the draft with the last round of comments.

Daniel Massey
	support for the draft with the last round of comments.

David Blaka
	I support Opt-In.

Joerg Bauer
	I also prefer OPT-IN.

Frederico Neves
	We strongly support OPT-IN. Today as the "standard" is we can't
deploy
DNSSEC without OPT-IN.

'Abstain with comments??'
-------------------------

David Conrad
	Sigh.  I've said I don't care what decision is made as long as a 
decision is made

Sam Weiler
	I still oppose opt-in, but for the moment I'm willing to step aside
and let it advance.

Rob Austin:
	I oppose opt-in, but would be willing to stand aside if the WG were
to
approach consensus in favor of opt-in

Steve Bellovin
	Agrees with Rob 'on both points' 

ted (NLnet Labs)
	This [Rob's text] is exactly also my position.

Miek Gieben 
	I totally agree with this. That is: I oppose opt-in, but ...

Brian Wellington
	- I am unable to find a clear statement of support or opposition.

Opposed
-------

Ted Hardie
	I oppose OPT-IN going forward as a proposed standard.  

[email-masked]
	I'm unprepared to just "move on" at this point, particularly as I
too
am one of the people opposed to OPT-IN (on grounds that have all been
presented by others here).

--
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: Brian Wellington <[email-masked]>
Date: Mon, 28 Apr 2003 10:35:17 -0700 (PDT)

On Sun, 27 Apr 2003, Hallam-Baker, Phillip wrote:

> ... 

You don't think:

Furthermore, the main argument for opt-in has historically been that full
DNSSEC would require too many resources.  Since this argument was 
originally used, probably 2 years ago, every conceivable resource has 
become both cheaper and faster, and the size of excessively large zones 
has more or less stayed the same.  This means that even if it had been a 
good argument in the past, it's days are over.

is a clear enough argument for opposition?  Just like last time you posted 
an "unbiased" summary, it's wrong.

I urge the working group chairs to either completely ignore this or come 
up with a truly unbiased list and compare it.

Brian

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Apr 2003 19:32:23 -0000

I oppose opt-in for an additional reason: it tends to hide security
problems.

Without opt-in, there's a clear difference between the current .com
security disaster (all records from .com can be forged) and the desired
situation (no records from .com can be forged).

With opt-in, the .com people will start proudly advertising ``DNSSEC
support'' (exactly as the BIND implementors have been doing for years)
when they still aren't protecting all their incoming and outgoing data.
This seems to be the basic reason that they support opt-in---they want
to claim security without doing the necessary work.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Apr 2003 16:44:46 -0400

>	Opposed	  2

I've said quite a bit on the topic, yet you don't list which side you 
think I am on.  Don't I get a vote too?

Sorry folks, I usually can refrain from snideness like this, but I'm 
beyond my limit of patience.

PS - Finally, hi-bandwidth is allegedly (newly) available in my 
"hi-tech" county.  The cable technician came today, with a service 
window of 1000-1400, promptly at 1500 with a tech who had just been 
hired to do this.  As he left, there's an "outage" so the 
installation couldn't be tested.  If the real Internet is this badly 
run, why are we trying to hard to over engineer the protocols?  (I'm 
still using 48K modem service.)

I can't wait for IPv6 service.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.

---

From: Roy Arends <[email-masked]>
Date: Tue, 29 Apr 2003 09:27:21 +0200 (CEST)

> situation (no records from .com can be forged).

All records under and including root can be forged anytime, anywhere. It's
error detection at the client side we're talking about. All authoritative
records are signed, with or without opt-in, and can be verified to be
valid or not. Opt-in removes redundant crypto. C'est ca.

> support'' (exactly as the BIND implementors have been doing for years)

Finally, about time, you should too !

> when they still aren't protecting all their incoming and outgoing data.

Who says they have to ? They need to do (at least) two things:

 1) sign authoritative RRsets.
 2) send them at request of the client.

badabing.

> to claim security without doing the necessary work.

They want to claim security without doing the unnecessary work.

Roy