[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in
At 09:10 AM 2/13/2003 -0800, Hallam-Baker, Phillip wrote:
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.
Note that David and Rob's reply dealt with the issues around section 3.1.1.
I have seen no replies about the concern raised about section 7 (more
explicit text on the interaction of opt-in and NXDOMAIN). I know Roy
has done some pretty extensive thinking on it, but that is not yet in
the draft. Others may disagree that it is needed, but no one
said so explicitly.
The workshop reports also indicated that the document
didn't agree with implemented behavior in regards to NXT
and needed to recommend against dynamic update;
here's the text from the report:
* specification issues
- draft & implementation behavior WRT NXT is different,
probably draft needs to change, on inclusion of negative
wildcard proof in the answer (draft says MUST NOT, code does
it, it's probably harmless, draft should say MAY)
- insecure delegation with opt-in NXT is semantically
ambiguous, useless, and doesn't work (SERVFAIL)
- draft should mention dynamic update behavior. It should
caution against dyanmic update with opt-in.
There was also the discussion among Rob, Johann, and Michael about
the need to rev NXT (and possibly SIG and KEY) to make the current
infrastructure distinguishable from the previous infrastructure. I
didn't say a resolution to this (though I may have missed it in a thread
permutation).
All comments made to the public list concerning the advancement of the
draft have been favourable to the advancement of OPT-IN.
There were comments, including in the workshop report, that
recommend updates to the specification.
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.
Please add the dynamic update and NXT issues to this list. I'm most
concerned, obviously, about the mismatch between tested implementations
and the spec on the NXT issue.
So the question for the chairs is what do we do next?
Speaking personally, I think the authors should rev the docs to fix these
spec bugs.
regards,
Ted
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.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>