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: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 13 Feb 2003 12:54:49 -0500

>There were 27 messages in this thread from 10 distinct individuals.

Thank you for your summary, I'm working on my own, but you are absolutely
correct there was strong showing of support for technical description
of OPT-in.
Expect the follow up WGLC to start this week.

         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: 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

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Feb 2003 10:30:29 -0800

Hi,

On Thursday, February 13, 2003, at 09:10  AM, Hallam-Baker, Phillip 
> Q: Is the description in the document of Opt-In complete ?

It would likely be the first RFC in the history of the IETF if it 
were... :-)

> 		implementation that has been tested?

To be clear:

Nominum has a delegation only opt-in validator implementation in our 
proprietary caching server.  The same person who wrote the opt-in 
validator for our prorietary server (Brian Wellington) also wrote a 
delegation only opt-in validator for BINDv9, but I'm not sure if that 
code has been incorporated into BIND.

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

> 	Conrad - To be perfectly honest, I no longer care

Out of context.  I do care that a decision is made, I just no longer 
care what that decision is.

Rgds,
-drc

---

From: David Blacka <[email-masked]>
Date: Thu, 13 Feb 2003 14:27:10 -0500

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.

> Speaking personally, I think the authors should rev the docs to fix these

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.
-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

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:
> 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>

Rgds,
-drc

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 14 Feb 2003 12:48:47 -0500

>          it, it's probably harmless, draft should say MAY)

this is a minor change, and wildcards in DNSSEC are a smaller issue
now than 2 months ago see
http://www.ietf.org/internet-drafts/draft-lewis-dns-wildcard-clarify-00.txt

>          caution against dyanmic update with opt-in.

There is (IMHO) no need to outlaw dynamic update in opt-in zone, but
there are some extra rules that are needed as well as update to
RFC2136.
This could be accomplished by a separate document while the
Opt-in document only says dynamic update of opt-in zones is unspecified.

In the following discussion updates to zone APEX are ignored as
they do not change at all.
Nit: Some of the confusion in the document results from inconsistent
terminology. The document seems to use the words "unsigned delegation" and
"unsecure delegation" interchangeably. That is not the case, in my mind
there is a difference between the two.
Unsecure delegation: A delegation without DS record.
Unsigned delegation: A delegation without DS but with a signed NXT.

If the working group concludes that the second is not allowed it does not
change the contents below.
In the text below I will only use the terms [un]signed name.
More terms:
         Local NXT == nxt with the same name as the update
         Previous NXT == NXT at the signed name lexicographically preceding
                         name updated.

For completeness all possible operations are included, in a delegation
only Opt-in case some operations do may change the signed status
as there only one RRset can be unsigned.
At unsigned names deleting the only RRset it is equivalent
of deleting the name.
Only DS RRset can be added to a delegation but that forces signing
of the node.
Note: NO == Does not change the contents of field
       YES == Contents of field changes, requires resigning this record.

                                               NXT  name
                                           local         previous
    case:updating signed name          Bitmap   Name   bitmap  name
         Modifying existing RRset        NO      NO      NO     NO
         Adding a RRset                  YES     NO      NO     no
         Deleting a RRset                YES     No      no     no
         Deleting a name                 NO      NO      no     YES
         Adding a name                   YES     YES     NO     YES

    case: updating unsigned name
         Modifying existing RRset        NO      NO      NO      NO
         Adding a RRset                  YES     YES     NO      YES
         Deleting a name/RRset           NO      NO      NO      NO
         Adding unsigned name            NO      NO      NO      NO

If a delegation can be signed without a DS RRset then the following
apply:
Changing security status of a delegation via Dynamic update
is not obvious and a special rule needs to be made up OR this
is done via server policy somehow.  This adds two cases
to the tables above.
    case: updating signed name
         Changing to unsigned           DELETE            NO      YES

    case: updating unsigned name
         Changing to signed             YES      YES      NO      YES

>didn't say a resolution to this (though I may have missed it in a thread

DS + OPT-in is a flag day, and the question is IF/HOW to signal this inside
the protocol, the options are
         do nothing,
         use a new ENDS0 flag to replace DO,
         change type code for NXT
         change type code for NXT SIG and KEY.

The reason against doing nothing is that some implementations really do not
like the NS  + NXT in authority section as specified in DS document.
This is a problem resulting from an under-specialization in RFC2535 as to
when NXT can appear in authority section. The implementation problem is
NXT specific. The advantage changing the NXT type code is then we have a
clean break with 2535 resolvers as they will not understand the new type
and the special processing that Opt-in and DS require.
In my mind there is no need to renumber SIG and KEY.

>Speaking personally, I think the authors should rev the docs to fix these

Speaking as a co-chair of DNSEXT:
After reading all the comments received and re-reading the document
it is clear to me the document needs updating before the next
last call can start. I will be working with my co-chair and the authors
on creating a list of changes and clarifications needed.
Thus the last call can not start until sometime next week.
         Olafur

---

From: Brian Wellington <[email-masked]>
Date: Fri, 14 Feb 2003 13:48:21 -0800 (PST)

> There were 27 messages in this thread from 10 distinct individuals.

I can't speak for anyone else, but I have problems with your analysis.
> 	Wellington - i believe that the current version of the

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.

> 		implementation has been tested.

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.

> 	Wellington - yes.  (notes to be posted here shortly, so they

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