Subject: Summary RE: DNSEXT WGLC: DNSSEC Opt-in

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Feb 2003 09:10:16 -0800

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    <[email-masked]> 
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.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Feb 2003 09:45:08 -0800

>                         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).

>draft have been favourable to the advancement of OPT-IN.

There were comments, including in the workshop report, that
recommend updates to the specification.

>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

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Feb 2003 12:04:22 -0800

Unfortunately Olafur's process did not set out the procedure for
dealing with any changes to the draft. Setting asside step 3 which
we can anticipate meeting Hobbes' description of the life of a man 
in a state of nature, how do we proceed with the document in the 
meantime?

If as appears to be the case these are all editorial issues that can
be dealt with in the normal post-last call process, should we wait for
an updated draft before going into last call or consider the period 
prior to Feb 12th as being a preamble to last call and deal with all 
the issues at once?

Since the Feb 12th date was not described as a last call are we now
required to repeat the last call and then comment in that period again
or do the comments already made count for that purpose?

Or considering that no objections were raised in last call and only
minor editorial issues with the document were raised in the Feb 12th
period do we simply resolve the outstanding issues and go ahead with 
submission to the IESG?

		Phill

> -----Original Message-----
> From: David Blacka [mailto:[email-masked]]
> Sent: Thursday, February 13, 2003 2:27 PM
> To: Ted Hardie; [email-masked]
> Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in
> 
> 
> On Thursday 13 February 2003 12:45 pm, Ted Hardie wrote:
> 
> > 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.
> 
> I haven't forgotten your concern, Ted.  I haven't commented on it yet
> because I haven't thought about it enough.
> 
> > 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;
> 
> Yes, I am aware of these issues as well.  I apologize for not having
> posted an open issues list to namedroppers by now (see the end of this
> message, however, for one).
> 
> At this point, however, I do not believe recommending against dynamic
> update with Opt-In is correct.  I don't think there is a real conflict
> between them.  But dynamic update should be mentioned in the draft.
> 
> > didn't say a resolution to this (though I may have missed it in a
> > thread permutation).
> 
> This issue is totally orthogonal to Opt-In.  I think you haven't seen
> a resolution to this issue because there hasn't been one.
> 
> > 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.
> 
> The workshop summary was somewhat unclear on the NXT issue.  It is far
> from a major one.  Essentially the draft forbids sending the negative
> wildcard proof NXT when sending an NXDOMAIN response.  We had two
> server implementations for opt-in: one which sent the negative
> wildcard proof and one that didn't.  Both worked.  So the draft is
> using a MUST when it should be using either SHOULD or MAY.  This was
> actually suggested by Ed Lewis before the publication of the -04
> version but got missed somehow.
> 
> I, as one of the authors, agree.  I believe that the other authors
> (Mark and Roy) also agree.
> 
> To summarize the "spec bug" issues list that I am aware of:
> 
>   * change the MUST NOT send negative wildcard proof to a SHOULD NOT
>     or MAY NOT (or some other language that means the same thing).
> 
>   * Clarify opt-in behavior wrt dynamic update.  (although I'm not
>     sure what the clarification should say).
> 
>   * In section 3.1.1, make it clear that a violation results in a
>     validation error.
> 
>   * Various additional warnings and comments to be placed in the
>     Security Considerations section.  This includes:
> 
>     o something about NXDOMAIN (although I'm not sure what needs to be
>       said about this).
> 
>     o some additional description of domain hijacking possibilities
>       (asked by Paul Vixie during the Atlanta dnsext meeting).  From
>       the minutes:
>     
>       There was a comment that security section needs stronger
>       language, Clearly list the need for zone transfer protection and
>       risk from zone hijacking of opt-outed delegations.  Authors
>       agreed examine if the current text is insufficient .
> 
> Anything else?
> 
> I'd like to point out that none of these proposed changes should
> affect existing implementations in any way.
> --

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Feb 2003 14:54:15 -0800

> prior to Feb 12th as being a preamble to last call and deal with all 

as usual, we will wait for a draft that is as good as we know it

randy

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Feb 2003 17:57:08 -0800

Sigh.

<embarrassment>
So I said:

On Thursday, February 13, 2003, at 10:30  AM, David Conrad wrote:
> Nominum has a delegation only opt-in validator implementation in our 
> proprietary caching server.

Turns out, I lied.  The only implementation of an opt-in validator I'm 
aware of is the one Brian did for BINDv9.

Oops.
</embarrassment>

However, the question still stands:

> Has anyone else written a validator that supports opt-in?

Rgds,
-drc

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 14 Feb 2003 18:07:11 -0800

Brian,

	Ooops, Sorry about that, somehow I managed to get your name
attached to Paul Vixie's comments one of which is in the wrong column.

	Probably the DNS Directorate using their confusion ray ...

		Phill

> From: Brian Wellington [mailto:[email-masked]]
> Sent: Friday, February 14, 2003 4:48 PM
> To: Hallam-Baker, Phillip
> Cc: 'Roy Arends'; Erik Nordmark; Ólafur Gudmundsson/DNSEXT co-chair;
> [email-masked]
> On Thu, 13 Feb 2003, Hallam-Baker, Phillip wrote:
> 
> I can't speak for anyone else, but I have problems with your analysis.
> > 
> I'm pretty sure I never said that.  I have implemented 
> opt-in, but am most 
> definitely not sure of its correctness and whether I missed 
> any corner 
> cases.
> 
> There are two questions here, and 'yes' implies yes to both.  
> Yes, there 
> are implementations.  No, I have never tested them and do not 
> know the 
> results of any tests that have been performed.
> 
> You've got to be kidding me.  I have never supported the 
> advancement of 
> opt-in.  I don't know what notes these are, since I haven't 
> publicly said 
> anything about opt-in in the last 6 months.
> 
> Check your facts before putting words in other people's mouths.
> 
> Brian
>