DNS Security (DNSSEC) Opt-In
RFC 4956

Note: This ballot was opened for revision 09 and is now closed.

(Ted Hardie) Yes

Comment (2006-10-11)
No email
send info
I think the working group faced a tough challeng here.  There were plenty of folks, myself included, who objected to opt-in on the grounds that it violated the principle of least surprise for applications that were expecting a "no" to have a reliable semantic.  I think the issues faced by large, flat zones are real, though, and that the working group met the challenge in a reasonable way--by making it possible to distinguish between those zones where the "no" has the expected semantic and those where it did not.  As the basis for further experimentation, this enough to see what troubles this creates in APIs and applications.

I do think this is enough for a proposed standard, and I would not support it as a change to the base semantics of dnssec.  After reflection, I do believe that this is enough to run a successful 
experiment.  I wish more of the later decision making process were already sketched out, but that is a matter for charter and DNSSEC chair activity.

(Mark Townsley) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-10-09)
No email
send info
I don't want to delay this draft but the Gen-ART reviewer was expecting a minor update for clarity:
http://www1.ietf.org/mail-archive/web/gen-art/current/msg01357.html

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(David Kessens) No Objection

(Dan Romascanu) No Objection

Magnus Westerlund No Objection

(Russ Housley) Abstain

Comment (2006-10-11)
No email
send info
  Opt-in allows a zone owner to avoid signing unsecured delegations, 
  avoiding a huge number of digital signature operations in 
  delegation-heavy zones (like TLDs) in which most of the delegations
  are unsecured.  Opt-in allows unsecured delegations to be spoofed
  and it allows new unsecured delegations to be inserted.

  In 2003, the DNSEXT WG failed to reach rough consensus on publishing
  opt-in on the standards track.  As I understand the result of this
  exercise, the DNSEXT WG was going to add some statement to the
  introduction of the document to indicate that they did not reach
  consensus to the content of this document, and then publish it as
  an informational RFC.  That never happened.
  
  I do not see how this experiment will lead to a better understanding
  of the security implication of opt-in.  I do not think we should
  experiment with the security model of DNSSEC.  Changes to the
  security model of DNSSEC require consensus.

(Cullen Jennings) Abstain

Comment (2006-10-12)
No email
send info
I am basically putting in a No-obj I defer to the opinion of security ADs.