There were 27 messages in this thread from 10 distinct individuals.
Olafur posed 3 questions as follows:
Q: Is the description in the document of Opt-In complete ?
Answers:
Kosters - Yes [detailed response]
Rose - I believe it is.
Loomis - I believe so.
Hardie - Raised issue with 3.1.1, possible issue with Section 7
Blacka - Stated that issue raised by Hardie had been tested
Could add text to draft, not sure it is
necessary
Austein - It would be a good idea to mention the issue [3.1.1]
explictly, but it's not a showstopper.
Arends - Yes
Q: Does this document satisfy people as being implement able and
testable
specification ?
Answers:
Kosters - Yes [detailed response]
Loomis - I believe that the specification can be implemented and
tested.
Wellington - i believe that the current version of the
specification
is complete.
Q: Are there implementations of opt-in and have there been any tests ?
Answers:
Kosters - Yes [detailed response]
Austein - asked about resolver side implementations
Arends - Yes, Verisignlabs and ISC have auth.server
implementations,
ISC has a resolver implementation.
Nordmark - Does this mean that there is a caching resolver
implementation that has been tested?
Arends - I don't have material on how thorough the caching
resolver
implementation has been tested.
Wellington - yes.
Vixie - In message prior to question stated that "OPT-IN softens
the
privacy-related impact of early dnssec deployment" and
"because
of some obscure corner cases which have shown up in
private
workshops that are much easier to isolate and to think
about
in an opt-in world."
In addition there were responses on the question of advancement
Hallam-Baker - It should advance
Vixie - dunno. but in any case i am strongly in favour of it
Conrad - To be perfectly honest, I no longer care
Wellington - yes. (notes to be posted here shortly, so they
tell me.)
Kosters - It should advance
Rose - It should advance
Loomis - I support the advancement of the current
Opt-In draft along the standards track.
In addition one poster observed "fun was had in amsterdam, the week
before ripe, and opt-in saw some testing." I presume the fun referred to
was review of the OPT-IN document.
All comments made to the public list concerning the advancement of the
draft have been favourable to the advancement of OPT-IN.
It has been established that the specifications have been tested in
server and resolver configurations. The remaining issue in that respect
raised by Eric yesterday was the issue of testing the caching behavior.
The posts describing the tests state that caching resolvers were tested.
We do not however have a statement that the testing was at the
thoroughness usually required when a specification advances to draft
standard.
There are two possible outstanding editorial issues concerning section 7
and section 3.1.1 but these are not rated as being significant enough to
prevent progress of the document.
So the question for the chairs is what do we do next?
Phill
--------------------
Detailed issues raised:
On Mon, 3 Feb 2003, Paul Vixie wrote:
dunno. but in any case i am strongly in favour of it, both because it
softens the privacy-related impact of early dnssec deployment (walking
a short nxt chain exposes less information than walking a full nxt
chain
would) and because of some obscure corner cases which have shown up in
private workshops that are much easier to isolate and to think about in
an opt-in world.
Kosters:
> 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
> specification ?
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
Ted Hardie
At 01:17 PM 2/4/2003 -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote:
>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
Blacka:
On Tuesday 04 February 2003 07:06 pm, Ted Hardie wrote:
> 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?
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 <davidb@verisignlabs.com>
Sr. Engineer Verisign Applied Research
Austein:
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.
Richardson:
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.
Attachment:
smime.p7s
Description: application/pkcs7-signature