Subject: Re: DNSEXT WGLC: DNSSEC Opt-in

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Tue, 04 Feb 2003 13:17:38 -0500

This working group last call concluded in December with NO comments,
there have been some comments in the last 24 hours.
The chairs would like a more affirmative statements from the working group
about this document.

Default action: if there is NO response to these questions Opt-in document
will be removed from the working group.

Note: We are only asking the technical questions about Opt-in, the political
question if we want to standardize this will be addressed if the
technical questions are affirmative.

Q: Is the description in the document of Opt-In complete ?

Q: Does this document satisfy people as being implement able and testable
specification ?

Q: Are there implementations of opt-in and have there been any tests ?

The chairs will consider any response received on the mailing list or
sent privately to BOTH chairs, by February 12'th.

	Olafur 

--
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: Mark Kosters <[email-masked]>
Date: Tue, 4 Feb 2003 15:30:19 -0500

> technical questions are affirmative.

I'm really puzzled by this process. Can you map this out for me please?

> Q: Is the description in the document of Opt-In complete ?

Yes. We had one quibble with opt-in using wildcards. The current draft
forbids the negative wildcard proof to be returned but the implementation 
we used did return the negative wildcard proof (that is, an additional NXT 
record was sent covering the non-existant wildcard). Perhaps the draft
needs to be relaxed to allow for the proof to be sent since it seems to
do no harm.

> Q: Does this document satisfy people as being implement able and testable

WRT opt-in, we tested with two authoritative servers (ISC and VeriSign) and
one opt-in aware recursive server (ISC). A mixture of delegations were
tested (fully secure, opt-in, and insecure) and all worked. So, it looks
to me like the specifications are clear.

> Q: Are there implementations of opt-in and have there been any tests ?

Yes. See above.  We had a workshop Jan 21-23 @ RIPE and I understand the 
results are going to be posted soon. Some of the tests run are listed
at http://www.verisignlabs.com/workshop/index.html.

And, I guess it should be no surprise that I support the advancement
of opt-in.

Mark

-- 

Mark Kosters            [email-masked]       Verisign Applied Research

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 4 Feb 2003 16:20:47 -0500

> Q: Is the description in the document of Opt-In complete ?
I believe it is.

> Q: Are there implementations of opt-in and have there been any tests ?
Hopefully this has been done and no show-stoppers have appeared.

Barring any problems that appeared from the test, I would like to see the
draft advanced.

Scott

---

From: Ted Hardie <[email-masked]>
Date: Tue, 04 Feb 2003 16:06:04 -0800

I had originally planned to wait to see what the test results showed before
posing this question, but given the exchange thus far it is probably worth
asking now.

>Q: Is the description in the document of Opt-In complete ?

I'm not sure that section 3.1.1 (delegations only) is complete.  Section 3.1.1
notes that servers and signers must enforce the restriction that only
delegations may exist between the owner and "next" names of an Opt-In
tagged NXT record.  It was not obvious to me how to handle the error
condition.  If, for example, a caching resolver receives a request for some
record, and gets an answer back that does not conform to 3.1.1, how
should it indicate the error to the original requester?  Was this one
of the conditions tested in the recent set of tests?  If so, how was this
handled?

I'm also not sure that section 7 adequately describes the risks inherent in
how Opt-In interacts with NXDOMAIN.  Though it makes the point
that all unsigned names are at risk for insertion, modification, or deletion,
it does not describe either the need for cryptographically assured denial
of existence or the affect that Opt-In would have on the ability to provide
it.  Were others satisfied that this text handled the issue?

                                 regards,
                                         Ted Hardie

---

From: David Blacka <[email-masked]>
Date: Tue, 4 Feb 2003 20:00:56 -0500

> of the conditions tested in the recent set of tests?  If so, how was this

This actually was tested.  Violations of any of the requirements of the spec 
result in a validation error, which is reported as a SERVFAIL.  When we 
tested this against our resolver implementation, we got SERVFAIL.  So it 
worked.

At the moment, I can't put my finger on where the protocol behavior of a 
validation failure is defined, but it probably should not be defined in the 
opt-in draft.  Editorially, I can see adding language that make it clear 
that violations of 3.1.1 must be handed as a validation error, but I'm not 
sure that it is necessary.  What do others think?

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Rob Austein <[email-masked]>
Date: Tue, 04 Feb 2003 20:47:41 -0500

> sure that it is necessary.  What do others think?

It would be a good idea to mention the issue explictly, but it's not a
showstopper.

---

From: Rob Austein <[email-masked]>
Date: Tue, 04 Feb 2003 21:06:06 -0500

> to me like the specifications are clear.

Not to be difficult, but the resolver side of opt-in is the hard part.
Is there a second iterative resolver implementation, and has it been
through any interoperability testing?

Not faulting anybody, just digging for whatever data we have.

---

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Tue, 04 Feb 2003 23:01:52 -0500

>I'm really puzzled by this process. Can you map this out for me please?

I'm real sorry to have to do this to you, but recent history of DNSEXT
forces us chairs to be extra careful and make sure there is documentation
in the working group mailing list supporting all actions we take.

Process for Opt-in:
Step 1: force people to publicly state that they have reviewed the document
         and what changes if any are needed.
         At the same time extract what ever information possible about
         implementations and testing for the public record.

Step 2: Chairs make a statement about technical soundness of document

Step 3: Once chairs declare specification is sufficiently good, the political
         discussion on "do we want to do Opt-in" will be started.

The thing that Randy and I want to avoid is people pointing at minor document
defect and use that to object to Opt-in in general.

>one opt-in aware recursive server (ISC). A mixture of delegations were

s/server/resolver/ ?

>to me like the specifications are clear.

This is exactly the kind of information we need.

>at http://www.verisignlabs.com/workshop/index.html.

please post the contents of this web page to the mailing list or include
relevant details in the report.[1]

>And, I guess it should be no surprise that I support the advancement

Thanks

         Olafur
[1] The reason I sometimes insist on posting the contents of web pages
to the mailing list has to do with my history background.
Message to mailing list is a record at particular time instant that can
be attributed to certain person, Web page is a living thing that
can be updated.
The analogy is the difference between a letter and word-of-mouth.

---

From: Roy Arends <[email-masked]>
Date: Wed, 5 Feb 2003 09:37:10 +0100 (CET)

> Q: Is the description in the document of Opt-In complete ?

Yes.

> Q: Does this document satisfy people as being implement able and testable

I did not implement it, nor was I able to test it during the last
test-round. No opinion here.

> Q: Are there implementations of opt-in and have there been any tests ?

Yes, Verisignlabs and ISC have auth.server implementations, ISC has a
resolver implementation.

Roy

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Feb 2003 09:47:00 -0500

-----BEGIN PGP SIGNED MESSAGE-----

I wonder if the final zone files, plus public and private keys from the
opt-in workshop could be made available fot FTP somewhere?

This would help others to duplicate this test environment in vitro,
(via bind9's on multiple aliases, or via User-Mode-Linux, or even by getting
X-many machines) to best understand the setup and configuration that was
done. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 7 Feb 2003 12:50:58 +0100

> opt-in workshop could be made available fot FTP somewhere?

As the setup was distributed over many laptops and the laptop have
dispersed this is at this point close to impossible.

> (via bind9's on multiple aliases, or via User-Mode-Linux, or even by
> getting X-many machines) to best understand the setup and
> configuration that was done.

I think you have a good point. Any future workshop should record all
zonefiles and keys. Maybe it's time to write up an I-D (BCP style) on
test setups. (Or is there allready an RFC)

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi