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: [email-masked] (Ted Lindgreen)
Date: Mon, 28 Apr 2003 10:29:19 +0200

[Quoting "Hallam-Baker, Phillip", on Apr 27, 16:44, in "Summary: DNSEXT WGLC ..."]

> Folk may want to check I recorded their statement correctly. ...

Please count my position as "I oppose OPT-IN".

-- ted (NLnet Labs)

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 28 Apr 2003 14:15:41 -0400

I'm opposed to opt-in (yes, dnsext context).

Eric

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 05:53:25 -0700

No, the call for votes was very clear, make a clear statement of
support or opposition. You made statements on the subject but
I was not going to interpret your statements for you.

> -----Original Message-----
> From: Brian Wellington [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 1:35 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN 
> 
> 
> 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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 05:48:47 -0700

18 -0700 4/27/03, Hallam-Baker, Phillip wrote:
> >Summary
> >	In favor 12
> >	Abstain	  7
> >	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?

I could not find a definitive statement from you during the 
last call.

And in any case it does not appear that you get a vote at
all in this group unless you vote the way Randy approves of.

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

So am I. This is now the FOURTH last call of this Florida style
decision procedure.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 05:51:38 -0700

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

As has been stated during the discussion on the OPTIN proposal the
security considerations of an unsecured delegation and a secured
delegation to an unsecured zone are exactly the same except in
one regard - an unsecure delegation is subject to a record 
insertion attack, a risk that is not relevant to the .com zone.

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

No, without doing unecessary work.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 06:03:43 -0700

Your actual statement was in response to Rob who stated he did not
think Opt-in was a good idea but would not object for the sake of
consensus.

This is exactly also my position.  I strongly feel that the problems
that OptIn may or may not solve or impose are dwarfed by the problems
we still have to face to get DNSSEC widely deployed. Most of the
work sofar has been done from the viewpoint of the DNS-administrator,
we still have to do a lot of work to make DNSSEC understood, working,
and useful for the user.

I do not believe that I misrepresented your statement during the last
call period.

Given the procedural manipulations and abuses by one of the chairs I
think folk will understand why this has to be played strictly by the 
originally stated rules at this point.

The last call was the FOURTH, each time the last call failed to go
the way Randy wanted a new last call was staged. 

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 4:29 AM
> To: Hallam-Baker, Phillip; [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Apr 2003 09:30:52 -0400

>I could not find a definitive statement from you during the

Thank you. ;)

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

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

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 29 Apr 2003 16:18:36 +0200

[Quoting "Hallam-Baker, Phillip", on Apr 29, 15:03, in "RE: Summary: DNSEXT  ..."]
> think Opt-in was a good idea but would not object for the sake of

Sorry, but according to my e-mail archive it appears that Rob
had written something different:

 [Quoting Rob Austein, on Mar 27, 11:14, in "Re: DNSEXT WGLC: To  ..."]
 > I oppose opt-in, but would be willing to stand aside if the WG were to
 > approach consensus in favor of opt-in, because I strongly agree that
 > we need to make a decision and put this behind us.

I interpreted Rob's words as that he would be willing to stand aside
if the WG were to approach consensus in favor of opt-in. And that
was also my position.

However, giving the fact that the WG is NOT approaching consensus
about opt-in, makes the "but would ..." part of the sentence no
longer relevant.

So _my_ position was, is and remains:

   I oppose opt-in

> I do not believe that I misrepresented your statement during the last

I believe you did, anyway, this is now straightend out.

> originally stated rules at this point.

And please don't do this. I, and everybody I've spoken with during
the years that I have been involved with the IETF, have high respect
for the chairs and I have never seen manipulations or abuses by
them. On the contrary, I think they do a terrific job.
The fact that not everybody applauds the OptIn idea is not because
of the chairs, it's because of the OptIn idea.

-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 09:10:29 -0700

> the years that I have been involved with the IETF, 

I have no respect for Randy and he told me during the very first 
meeting I attended, before I had ever said a word beyond my name and
company, that he had no respect for me.

Several people have represented to me that I am the one creating this
issue. That is simply untrue and unsupported by the facts. On the
contrary you will find that in the past 36 months I have been a
signficiant if not principal contributor to the core specifications
of Web Services Security. I have brokered many of the agreements 
between the fiercest rivals in the space.

I suggest that the opponents of OPTIN consider their actions and
ask whether my statements that I may not accept the decision of
the group might have been based on their own statements such as
'I don't believe deployment in .com is important'. If a WG decides
not to address my needs I am under no duty, moral or otherwise
to accept the decision of that group. If telling you that gives
offense then take it.

If it really is true that this working group cannot work with me
then that speaks more for this group than it does for me.

I have two choices here, appeal or simply deploy a DNS Security solution
without IETF sanction. 

I do not believe that the sanction of this group counts for very much 
in the cryptography world, and it is that world my world, which will 
decide whether to sanction deployment of any DNS Security solution or not.

This group has repeatedly told me not to make statements of this
type that they feel are threatening. Well, sorry if it bursts your
bubble if I tell you that in the world of commercial deployment of
cryptographic protocols you will find that I am the only major voice
with standing that is supporting DNSSEC at all.

Name one other front line champion from the commercial cryptography
world who is going to persuade Microsoft or any other major vendor 
to deploy DNSSEC. IF DNSSEC is not deployed in end points the end
to end argument collapses and you are better off with link security
which will be easier to deploy.

This process has been a farce from beginning to end. The only reason
that I am willing to make an appeal is that I believe that the actions
of this group do not reflect those of the IETF in general.

Randy has deliberately constructed this procedure to give himself
the maximum opportunities to obtain the result he has wanted from
the outset.

My purpose in summarising the votes was not to address the consensus
issue, it was to force the chairs to announce their decision so
the process can move on to the next stage. 

I am not prepared to play another round of procedural games in
this forum.

The issue of consensus is not the principal issue that the appeal
is based on. The principal issues are technical merit and due 
process. 

Frankly the consensus of this group on the issue of facilitating
deployment by the largest operator of DNS services does not appear
to me to be a useful question to ask.

		Phill

---

From: Brian Wellington <[email-masked]>
Date: Tue, 29 Apr 2003 09:22:42 -0700 (PDT)

> the way Randy wanted a new last call was staged. 

Rather than making unfounded accusations, maybe you should consider the
fact that during the first 3 calls, as well as this one, there was nothing
resembling working group consensus in either direction.

Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 10:02:58 -0700

Actually there was consensus recognized on the technical issues in the
previous last call.

The last call before that had no comments, but those in favor were under the
impression that the last call was a last chance for those opposed to say so
or forever hold their peace.

I would certainly have posted if not for the request of opt-in opponents to
avoid striring up more argument in the group, to simply let the matter pass
quietly. My trust was abused on that occasion, never again.

There was also consensus at the first last call. Otherwise it would not have
been necessary to make the unanounced referral to the DNS Directorate which
held the process up for 6 months but never reported to the group.

The procedures that this group has acted under are simply not defensible. 

Fortunately the decision is no longer in the hands of this group or Randy.
Further argument here is futile, but that won't stop it of course.

		Phill

> Sent: Tuesday, April 29, 2003 12:23 PM
> Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 10:25:11 -0700

I was responding to the following question:

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

And yes I too pointed out that, no Edward does not get a 'vote'.

When Bush is involved you have to wait for the decision of the 
Supreme Court.

		Phill

> From: Randy Bush [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 1:13 PM
> > the call for votes was very clear
> 
> there was never a call for votes.  no surprise, this is the ietf.
> 
> there was a call for people to state their expert opinions.  thanks
> to those who have done so.
> 
> randy
>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Apr 2003 06:44:03 -0000

Hallam-Baker, Phillip writes:
> the security considerations of an unsecured delegation and a secured
> delegation to an unsecured zone are exactly the same

The same argument cuts both ways. To fix the existing security disaster,
we have to secure all the zones _and_ we have to secure the delegations.
If the .com people were prepared for this, they wouldn't need opt-in.

Opt-in allows the .com people to claim full DNSSEC support when the
reality is that they can't handle a DNSSEC universe. It takes a failed
security system and tries to pretend that it's a working system.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 30 Apr 2003 05:41:49 -0700

Dan,

	What value do you claim there is to securing the delegation without
any security on the delegated zone?

	There has been a lot of security analysis on this issue, the only
security issue that has been raised is that of preventing an insertion
attack, a risk that is not relevant to a domain where anyone can buy a
domain.

	All anyone is talking about is adding crypto to the DNS, that is not
by any step of the imagination eliminating all risks, regardless of whether
you deploy with or without OPTIN. 

	Security is risk control, not risk elimination. Systems that attempt
to eliminate all risks, even those not relevant to a particular deployment
tend not to be deployed. We have had ten years of non-deployment here. Do
you really want to wait another ten?

	Without OPTIN DNSSEC becomes even more expensive to deploy than
PKIX. That is quite some feat.

			Phill

> From: D. J. Bernstein [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 2:44 AM
> To: [email-masked]

---

From: Sam Weiler <[email-masked]>
Date: Wed, 30 Apr 2003 14:24:40 -0400 (EDT)

On Wed, 30 Apr 2003, Roy Arends wrote:
>
> Protection against your deletion ("spoof a zone out of existence") attack:
> sign the delegated zone.
>
> A secured delegation to an unsecured zone is as practical as an unsecured
> delegation.

Roy,

As Dan so ably points out, signing a child zone won't protect it from
someone corrupting the NS glue, whether or not there's a DS in the
parent.  But adding the NXT to the parent, with or without a DS,
signals the existence of the delegation.  A client seeing an NXT at
least knows that the delegation exists.  It may not know how to find
it, for inability to get the glue or because it was fed bad glue, but
it knows that it's there.  That's a different and more informative
failure mode, and there may be ways of recovering from it.

In an opt-in zone (in an unsecure span), you're telling the client to
fallback to the current state of the world: there's no reason to
believe that there's anything in the span.  Without opt-in, you know
something should be there, and you can try to recover (not that we
know how, yet).  And whether or not the child is signed makes no
difference.

Yes, this would be much more interesting if the parent signed the
glue.  Too bad we're not redoing delegations at this point in the
process.

Yesterday, you wrote:
> All authoritative records are signed, with or without opt-in, and
> can be verified to be valid or not.

Correct, but misleading.  The parent is authoritative for the
existence of a delegation, and the existence is proved with an NXT and
SIG(NXT).

So while the parent isn't authoritative for the NSset, it is making an
authoritative statement by the inclusion of a NXT.  Without opt-in, it
makes an authoritative statement by the omission of a NXT ("there's
nothing to see here, move along").  With opt-in, omission of the NXT
is ambiguous.

-- Sam

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 30 Apr 2003 13:45:04 -0700

> > All anyone is talking about is adding crypto to the DNS
> 
> Security is not some optional feature that we want a few 
> people to ``opt
> in'' to. We need a security system that works for _all_ DNS records.

Tough, there is no way of securing www.xyz.com unless xyz.com chooses
to deploy DNSSEC in the zone.

So your argument does cut both ways.

> Evidently the .com people don't think they can sign all their records.
> That's a serious problem. It has to be fixed. Opt-in doesn't fix it.
> 
> Communication from the zone server is often secured by 
> mechanisms other
> than DNSSEC. But this is a side issue.

no it isn't it is absolutely the central issue.

Trying to pretend that securing dotCOM is relevant if the subdomains 
are insecure is precisely the bogus security you are arguing against.

> I'm talking about a different situation, the situation we're 
> aiming for:
> namely, having _all_ zones signed. The .com people can't handle this.
> Opt-in doesn't help the .com people handle it. Opt-in tends 
> to hide the
> fact that they can't handle it.

If you want dotcom signed then best provide a spec that meets the
criteria of the operator.

If you want to propose an alternative that meets those criteria
then do so.

	Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 30 Apr 2003 13:48:56 -0700

Sam,

	If someone is going to go to the trouble of deploying an IDS
that is intelligent enough to do what you propose and they are 
going to have someone monitor it at minimum wage then they are going
to be able to afford whatever it ends up costing in time, effort and
so on to enable DNSSEC.

		Phill

> From: Sam Weiler [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 10:15 AM
> On Wed, 30 Apr 2003, Hallam-Baker, Phillip wrote:
> >
> There's also the deletion ("spoof a zone out of existence") attack.
> You can still replace the NS and make the zone unreachable, but you
> could have done that just by stomping on the whole answer; DNSSEC
> doesn't guarantee that packets get through.  Without opt-in, assuming
> you get an answer at all, you at least get a verifiable statement of
> existence -- you know that such a delegation exists and that something
> is preventing you from reaching it.  That could trigger an IDS's alarm
> bells, or it could tell you that you need to try harder to get the
> answer.
> 
> Assuming that methods for "trying harder" are developed, you probably
> don't want clients trying them all the time -- they'll probably be
> bandwidth intensive or they'll try to get around caches and end up
> pounding authoritative servers into the ground.  As an operator of
> authoritative servers, your employer may be interested in minimizing
> those events.  One way of doing that is to provide a very clear
> trigger for when it's required.  You don't want all NXDOMAINS to turn
> into a "flail on the auth servers" fest.
> 
> -- Sam
> 
> 
> --