Subject: Re: chairs' message on opt-in

From: Edward Lewis <[email-masked]>
Date: Mon, 5 May 2003 11:56:30 -0400

At 18:34 -0700 5/4/03, Randy Bush wrote:
>     there is no consensus to add opt-in.

"Add" it to the standards track?  My question is about the word "add."

 From the chairs' message, it seems to me that the only negative 
comments on opt-in involve such words as "probably" and "opinions 
differ."  Given that I don't see any definitive statement that opt-in 
is a detriment to network operations and that it seems that the 
negative statements are founded in uncertainty, I feel compelled to 
suggest that perhaps opt-in be declared experimental.

I'm basing this suggestion on the document's maturity and 
completeness, albeit about a potentially risky proposition.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Note to pilots: a three-point landing SHOULD NOT include a wing.

--
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: "Scott Rose" <[email-masked]>
Date: Mon, 5 May 2003 12:32:07 -0400

----- Original Message -----
From: "Edward Lewis" <[email-masked]>

> >     there is no consensus to add opt-in.
does this mean there is a consensus to not add opt-in?  Given some recent
traffic, my opinion is that some still want to see it in some form.

> completeness, albeit about a potentially risky proposition.

If it is declared experimental, will there be a mechanism to alert a
resolver that the zone uses OPT-IN?

Scott

---

From: Roy Arends <[email-masked]>
Date: Mon, 5 May 2003 19:35:26 +0200 (CEST)

> resolver that the zone uses OPT-IN?

Well, the resolver can flag through edns its compliance with opt-in.

Roy

---

From: Brian Wellington <[email-masked]>
Date: Mon, 5 May 2003 10:51:04 -0700 (PDT)

> Well, the resolver can flag through edns its compliance with opt-in.

This would involve adding such a flag to the opt-in spec.  I remember 
suggesting this years ago.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 May 2003 15:01:24 -0400

>Well, the resolver can flag through edns its compliance with opt-in.

Roy,

I hope you just forgot the ';)' on that one. ;)

I don't think it would be easy to make opt-in a 'versioned' feature 
due to the nature of opt-in.  I think that if the resolver were to 
say 'I do opt-in' it is really just asking the server if there is a 
DS for the referral, even if the referral is part of an unsigned 
zone.  That sounds ugly.

I also cringe every time we consider adding option negotiation to the 
DNS protocol.  (I've had this out with Paul already. ;))  If we went 
back to the start, we ought to have used extra types and relied 
strictly on the three Q's for how an answer was prepared instead of 
EDNS0.  We can't go back and right that wrong, but we can try to stop 
it from happening again.

Still, if opt-in were to be on the experimental track, then maybe 
we'd want the DNSSECbis documents to specify that the NXT bit in the 
NXT would be set to 1 by the signer (the data preparer) and ignored 
in the verifier.  DNSSECbis would also have to say that if the QNAME 
is between the NXT's owner name and its next name, then  the QNAME 
should be considered not to exist - and that causes a problem for an 
experimental opt-in zone.

Or maybe we could say that if the NXT bit is 0 in an NXT, then the 
verifier is to treat the NXT as existing (I've got it), but ignore 
any proof of non-existence it yields.  E.g., if the bit is 1 as it 
should be, then the rigid semantics hold.  If the bit is 0, then 
something else is going on - Akin to bit for RR type 0, the extended 
format bit.

Then, when DNSSECbis gets to proposed standard, if the opt-in 
experiment fails, the bit value of 0 is considered obsolete.  If the 
opt-in experiment succeeds, then the experiment specification is 
rolled into the proposed standard.

Sorry if I seem like someone who is just trying to string along 
opt-in after it has been declared to be whatever it has been declared 
to be, but 1) I'm not clear on what the chairs mean and 2) think that 
it's not too late to find a consensus.

(Especially here, where there's no consensus for opt-in, no consensus 
against opt-in, just no consensus yet, as far as I can tell from the 
chairs' message.)

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 May 2003 15:17:07 -0400

sed "s/proposed/draft/g"
At 15:01 -0400 5/5/03, Edward Lewis wrote:
>experiment fails,
>the bit value of 0 is considered obsolete.  If the opt-in experiment succeeds,
>then the experiment specification is rolled into the proposed standard.
^D

---

From: Sam Weiler <[email-masked]>
Date: Mon, 5 May 2003 18:41:23 -0400 (EDT)

> Well, the resolver can flag through edns its compliance with opt-in.

Except that client signaling doesn't achieve opt-in's goals -- the
onus would be on the server to support non-opt-in clients, which means
signing everything anyway.

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Tue, 6 May 2003 18:44:55 -0400 (EDT)

> against opt-in, just no consensus yet, as far as I can tell from the

Independent of the working group's (lack of) consensus, the IETF
process on opt-in hasn't finished.  For AD/IESG/IAB appeals to be
meaningful, we have to retain the ability to implement what is
decided, which may include adding opt-in.

Unlike adding new RR types and many other DNS changes, opt-in is not
backward compatible -- a non-opt-in resolver should refuse an opt-in
(unsigned, unsecure) referral.  If enough of those resolvers get
deployed, then opt-in is dead in the water, and the remaining IETF
process becomes irrelevant.  In keeping with the grand tradition of
"be liberal in what you accept", the safe course of action is to
include something that is forward-compatible with opt-in.

Ed's on the right track, but architecting that change is likely to
take a while.  I'd rather just require that clients that understand DS
and the new type codes also have opt-in support, at least for the time
being.  It's already been implemented and tested extensively -- we
know it works, and while it adds (minimal) complexity, it does not
impact security unless zones are signed with opt-in.  Anything else
done to make the existing protocol forwarders-compatible is likely to
be just as complex and require new work.  And if/when we reach
consensus that opt-in is bad, we can remove the resolver support.

This keeps the door open for opt-in and allows client code to ship
today (or as soon as DS and the type code roll advance), which
satisfies my top goal: rapid deployment.  The alternatives are
shipping code that doesn't allow for opt-in at all, which slams the
door on the appeals process, or holding off on shipping code until the
process concludes, which I REALLY don't want.

Yes, this is an opt-in opponent saying "any clients that ship today
need to have opt-in support".  Given that the process hasn't
concluded, I think that's the only safe way to move forward.

-- Sam