DNS Security (DNSSEC) Opt-In
draft-ietf-dnsext-dnssec-opt-in-09

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

Lars Eggert No Objection

(Mark Townsley; former steering group member) Yes

(Ted Hardie; former steering group member) Yes

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.

(Brian Carpenter; former steering group member) No Objection

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

(Dan Romascanu; former steering group member) No Objection

(David Kessens; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Lisa Dusseault; former steering group member) No Objection

(Magnus Westerlund; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Cullen Jennings; former steering group member) Abstain

I am basically putting in a No-obj I defer to the opinion of security ADs.

(Russ Housley; former steering group member) Abstain

  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.