Subject: Reminder: WGLC dnssec-experiments and dnssec-opt-in

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 8 Mar 2006 16:43:11 +0100

Before people forget that we are collecting statements for dnssec- 
experiments, here is a reminder.

> This working group last call will terminate March 15. We request at
> least 5 people to state that they thoroughly read said documents
> before we forward to the IESG.

We have not reached a head count of 5 yet. One more week for review!

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: "Roy Arends" <[email-masked]>
Date: Wed, 8 Mar 2006 17:00:25 +0100

> We have not reached a head count of 5 yet. One more week for review!

I will review dnssec-experiments and will send comments (if any).

Roy

--
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: "Scott Rose" <[email-masked]>
Date: Wed, 8 Mar 2006 11:08:39 -0500

I read previous versions of these drafts.  I will go over them again.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Olaf M. Kolkman
> Sent: Wednesday, March 08, 2006 10:43 AM
> To: Olaf M. Kolkman
> Cc: Namedroppers
> Subject: Reminder: WGLC dnssec-experiments and dnssec-opt-in
> 
> 
> 
>

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 08 Mar 2006 12:20:23 -0500

Dear Olaf:

I reviewed (thoroughly read and assessed it) 
draft-ietf-dnsext-dnssec-experiments-02.txt.

I have no objection that it proceeds. So you may count me as a reviewer 
who accepts this draft to be forwarded to the IESG.

Olaf M. Kolkman wrote:

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 08 Mar 2006 12:50:33 -0500

> > before we forward to the IESG.

High-level, coming from someone who may not be terrible DNSSEC savvy.

I'm a bit confused about exactly what one is testing under this
methodology. There is a lot of discussion about using a private
algorithm, in which case those not participating in the experiment
will simply not recognize the signature and ignore it. That part seems
fine.

But, what exactly is being tested here? Is it real modifications to
the DNS protocols (i.e., changing/extending semantics of existing
operatiosn)? Or is it _just_ experimenting with a new signing
algorithm?  Is the idea that knowing the private algorithm (which
often isn't really an unknown algorithm, since the purpose apparently
isn't to test new algorithms) provides a way of indicating that "the
DNS protocol behaves differently for names in this zone"? 

It might help to show a concrete example of an example extension
(e.g., a past proposal) that could be tested using this scheme.

Specific comments:

abstract says:

>    In the long history of the development of the DNS security extensions
>    [1] (DNSSEC), a number of alternate methodologies and modifications
>    have been proposed and rejected for practical, rather than strictly
>    technical, reasons.  There is a desire to be able to experiment with
>    these alternate methods in the public DNS.  This document describes a
>    methodology for deploying alternate, non-backwards-compatible, DNSSEC
>    methodologies in an experimental fashion without disrupting the
>    deployment of standard DNSSEC.

IMO, the first sentence can be struck completely, as it adds nothing
to the purpose of the document.  I also don't like the wording, since
I don't know the difference between "technical" and "practical"
reasons.

>    For example, an experiment might specify in its description the DNS
>    name "dnssec-experiment-a.example.com" as the base name, and provide
>    the mapping of "3.dnssec-experiment-a.example.com" is an alias of

parsing problem???
Perhaps: s/and provide the mapping of/and declare that/
      
>    DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
>    an alias of DNSSEC algorithm 5 (RSASHA1).

same issue.

>    Resolvers MUST then only recognize the experiment's semantics when
>    present in a zone signed by one or more of these private algorithms.

Awkword wording (and I am not sure at all MUST is appropriate here, or
indeed what it is that is intended to be said here.)  Do you mean
something like:

    Only resolvers participating in the experiment would recognize the
    experiment's semantics when present in a zone signed by one or more
    of these private algorithms.
 
> 6.  Considerations
> 
>    There are a number of considerations with using this methodology.
> 
>    1.  Under some circumstances, it may be that the experiment will not
>        be sufficiently masked by this technique and may cause resolution
>        problem for resolvers not aware of the experiment.  For instance,
>        the resolver may look at the not validatable response and
>        conclude that the response is bogus, either due to local policy
>        or implementation details.  This is not expected to be the common
>        case, however.

Odd to say this, since the above is essentially a violation of
existing specs, as indicated earlier. Right?

>    2.  It will not be possible for DNSSEC-aware resolvers not aware of
>        the experiment to build a chain of trust through an experimental
>        zone.

Can't an experimental zone co-exist with a regular zone (i.e., one
using a standard signature)? If so, the above wording seems wrong. 

> 7.  Transitions
> 
>    If an experiment is successful, there may be a desire to move the
>    experiment to a standards-track extension.  One way to do so would be
>    to move from private algorithm numbers to IANA allocated algorithm
>    numbers, with otherwise the same meaning.  This would still leave a
>    divide between resolvers that understood the extension versus
>    resolvers that did not.  It would, in essence, create an additional
>    version of DNSSEC.

This is funny defn. of "version". [note: I think answering earlier
question will clarify my confusion here.]

> 9.  IANA Considerations
> 
>    IANA may need to allocate new DNSSEC algorithm numbers if that
>    transition approach is taken, or the experiment decides to use
>    allocated numbers to begin with.  No IANA action is required to
>    deploy an experiment using private algorithm identifiers.

Better (for IANA, and for this document):

   This document provides a way of experimenting with DNSSEC using
   the existing DNSSEC Private Algorithm Identifier space. No
   coordination with IANA is needed.
   
   This document has no IANA actions.

---

From: Mark Kosters <[email-masked]>
Date: Wed, 8 Mar 2006 13:14:03 -0500

> We have not reached a head count of 5 yet. One more week for review!

I have thoroughly read these both of these documents* and think they are
ready to send to the IESG.

Regards,
Mark

*I'm one of the co-authors of draft-ietf-dnsext-dnssec-opt-in-08.

-- 

Mark Kosters            [email-masked]               VeriSign

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 8 Mar 2006 16:47:17 -0500

I have finished going over the documents.  I do not have any objections to
both drafts proceeding.

Scott

---

From: Rodney Joffe <[email-masked]>
Date: Mon, 13 Mar 2006 09:25:17 -0700

Hello Olaf,

> We have not reached a head count of 5 yet. One more week for review!

I've reviewed both of these latest drafts in detail:

     draft-ietf-dnsext-dnssec-experiments-02
     draft-ietf-dnsext-dnssec-opt-in-08

I'll leave the nits for others, but add me to the list of reviewers  
who agree with these versions and approve them going forward to the  
IESG.

Rodney Joffe
UltraDNS Corp.

---

From: Matt Larson <[email-masked]>
Date: Mon, 13 Mar 2006 14:57:10 -0500

On Mon, 27 Feb 2006, Olaf M. Kolkman wrote:
> Please carefully review the methodology described in
> dnssec-experiments and review if the methodology has been correctly
> applied to the opt-in draft.

I have read both documents and recommend that they go forward to the
IESG.

Matt

---

From: Geoffrey Sisson <[email-masked]>
Date: Wed, 15 Mar 2006 18:03:07 GMT

I have reviewed draft-ietf-dnsext-dnssec-experiments-02 and believe it
is ready to be forwarded to the IESG for consideration for publication
as a standards-track RFC.

Nits:

- Should RFC 2119 be a normative reference rather than informative?

- "DNSSEC-aware" is presumably the same thing as "security-aware" in
  RFC 4033, but it may be a good idea to state this explicitly.

- In Section 4, second-to-last paragraph, "experiments" should 
  be "experiment's" (with apostrophe).

- In Section 5, paragraph 2, "may" should probably be "MAY".

Suggestions:

- In Section 6.1, change "the not validatable response" to
  "a non-validatable response"?

- In Section 6.2, change "not aware" to "unaware"?

Geoff

---

From: Geoffrey Sisson <[email-masked]>
Date: Wed, 15 Mar 2006 21:24:30 GMT

I have reviewed draft-ietf-dnsext-dnssec-opt-in-08 and believe it
is ready to be forwarded to the IESG for consideration for publication
as an experimental RFC.

Nits:

- RFC 3090 is obsoleted by RFCs 4033-4035?

- RFC 3655 is obsoleted by RFCs 4033-4035?

- Section 6: The example queries/responses appear to mix the idea of 
  queries sent to an auth, non-recursive server with responses with
  meaningful AD bit values, which would only originate from a validating
  resolver.  (The intent is clear, however, so could be left as-is.)

Suggestions:

- Section 2, paragraph 1: change "unsecured zones" to "insecure zones"

- Section 2, paragraph 1: change "authenticating existence" to
  "authenticating the existence"

- Section 3, paragraph 1: change:
    
    "Resolvers wishing to validate Opt-In zones MUST only do so when the
    zone is only signed using one or more of these private algorithms."
  
  to
    
    "Resolvers wishing to validate Opt-In zones MUST only do so when the
    zone is signed using only one or more of these private algorithms."

  (Parallelism with previous sentence.)

Geoff

---

From: Sam Weiler <[email-masked]>
Date: Fri, 17 Mar 2006 18:10:14 -0500 (EST)

I've reread the experiments draft.

I have only one issue I'd like to see addressed before the document is 
advanced: in section 7 (Transitions), I'd like this draft to mention 
using new DS hash algorithm identifiers as another transition option. 
Otherwise, I believe this document should be published on the 
standards track.

Nits:

As others have said, add an explicit: "No IANA actions needed" to 
Section 9, possibly moving the rest of the text into section 7 (or 
otherwise highlighting that the text is for the benefit of the 
readers, not the IANA).

Remove the citation from the abstract

Fix incomplete sentence in 1.

2: remove comma
OLD:  There has typically been a desire to both
    introduce non-backwards-compatible changes to DNSSEC, and to try
    these changes on real zones in the public DNS.
NEW: There has typically been a desire to both
    introduce non-backwards-compatible changes to DNSSEC and to try
    these changes on real zones in the public DNS.

2: explain or remove "public"
OLD:    This document describes a standard methodology for setting up 
public DNSSEC experiments. 
NEW:    This document describes a standard methodology for setting up 
DNSSEC experiments.

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Mon, 20 Mar 2006 20:58:00 -0500 (EST)

I've reread parts of the opt-in draft.  I hope to review it more 
thoroughly, but in the interest of publishing my written objection in 
advance of tomorrow's meeting, I'm sending the partial review now.

While I'm generally in favor of this document being published, I 
oppose it going forward in its present form.

In particular, I don't share the level of certainty expressed in this 
sentence from the abstract: "Maintaining this cryptography is not 
practical or necessary."  I think a few more qualifiers are 
appropriate.

The above can be easily fixed, and I think the document is close to 
being publishable.  That said, I suspect a few more eyes would be 
helpful -- this document has some subtle details that could benefit 
from extremely close scrutiny.

Other substantive questions:

A protocol correctness question, from section 4.2.1:

    As stated in the "Server Considerations" section above, this
    specification restricts the namespace covered by Opt-In tagged NSEC
    records to insecure delegations only.  Thus, resolvers MUST generate
    a validation failure when encountering records other than NS or glue
    that fall within an Opt-In NSEC record's span.

If a server is authoritative for both an opt-in signed parent and 
an unsigned child, what happens when the resolver receives an A record 
from the child zone?  The resolver doesn't see the NS record ...

Why the requirement for "clear path" in section 7?  Why do 
intermediate caches (whether validating w/ non-opt-in DNSSEC or not) 
need to understand opt-in?

Clarity/nits:

In section 3, this paragraph could be confusing, and its second
sentence seems particularly out of place (what's the antecedent for 
"this"?).
OLD:
    Servers wishing to sign and serve zones that utilize Opt-In MUST sign
    the zone with only one or more of these private algorithms. This
    requires the signing tools and servers to support private algorithms,
    as well as Opt-In.
NEW
    Servers wishing to sign and serve zones that utilize Opt-In MUST
    sign the zone with only one or more of these private algorithms and 
MUST NOT use any other algorithms.  In particular, the zone MUST NOT 
mix these private algorithms with any non-experimental algorithms.

Also:
OLD
    Resolvers wishing to validate Opt-In zones MUST only do so when the
    zone is only signed using one or more of these private algorithms.
NEW
    Resolvers MUST NOT apply the special opt-in validation rules in 
this document unless a zone is signed with one or more of these 
private algorithms.

---

From: David Blacka <[email-masked]>
Date: Mon, 20 Mar 2006 22:28:35 -0600

On Mar 20, 2006, at 7:58 PM, Sam Weiler wrote:

> thoroughly, but in the interest of publishing my written objection  
> in advance of tomorrow's meeting, I'm sending the partial review now.
>

I'm sorry to hear that.

> In particular, I don't share the level of certainty expressed in  
> this sentence from the abstract: "Maintaining this cryptography is  
> not practical or necessary."  I think a few more qualifiers are  
> appropriate.

So noted.

> from extremely close scrutiny.

Other than its experimental status, this document *has* benefited  
from extremely close scrutiny.  I'm not sure why, specifically, you  
think it needs more.

> an unsigned child, what happens when the resolver receives an A  
> record from the child zone?  The resolver doesn't see the NS  
> record ...

This isn't a special case.  This happens in non-opt-in DNSSEC.  What  
do you think happens there?

> intermediate caches (whether validating w/ non-opt-in DNSSEC or  
> not) need to understand opt-in?

Because an intermediate cache will not (necessarily) be able to  
reconstruct opt-in responses from its cache.

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

---

From: Sam Weiler <[email-masked]>
Date: Wed, 22 Mar 2006 00:53:49 -0500 (EST)

>> That said, I suspect a few more eyes would be helpful -- this 
>> document has some subtle details that could benefit from extremely close 
>> scrutiny.
>

(Assuming that you want your expression of uncertainty to be treated 
as a question...)  In my limited reread of this document, I found an
unexpectedly high density of phrases that puzzled me or that I feared 
could be misread (see examples in my last note).  I also noticed that 
a number of those who responded to Olaf's WGLC reminder only commented 
on the experiments draft, not opt-in.  And I noticed that of those who 
had read opt-in, most didn't send any nits to namedroppers.  Given 
that the document contains some boring details (like the examples, 
which I entirely skipped on this reading), I feared that things had 
been missed.

All that said, I didn't quite say it "needs" more -- I added a few 
more qualifiers to my attempt to draw out further reviewers.

>> If a server is authoritative for both an opt-in signed parent and an 
>> unsigned child, what happens when the resolver receives an A record from 
>> the child zone?  The resolver doesn't see the NS record ...
>
> This isn't a special case.  This happens in non-opt-in DNSSEC. 
> What do you think happens there?

My fear is that we get a Failure validation result, for want of having 
clearly told resolvers how to distinguish between the case I described 
and the case where is there isn't a delegation (and the A record is in 
the parent zone).

Would you walk through the process (whether from rfc4035 or 4.2 of 
this document) for this example?

Query:  child.example A  (sent to server authoritative for both
 	example and child.example)
Answer: that A record (and nothing else)

Does the resolution process then go on to prove that there's a 
delegation to child.example?  If not, how do we separate this case 
from the one where this is no delegation to child.example (which, per 
the quoted text, MUST generate a validation failure)?

> reconstruct opt-in responses from its cache.

Would you give me an example?

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Sat, 25 Mar 2006 23:39:04 -0500 (EST)

Last week, David and I talked more about opt-in section 4.2.1, which 
results from the delegation-only requirement this WG imposed on opt-in 
some time ago.

This section requires, with a 2119 MUST, resolvers to "generate a 
validation failure when encountering records other than NS or glue 
that fall within an Opt-In NSEC record's span."  We concur (I think) 
that neither this document nor DNSSECbis specifically tell a resolver 
how to do that, and, in particular, that it may need to explicitly 
look for a delegation if it receives unsigned records from within an 
opt-in span (which might happen if a single server is authoritative 
for both the opt-in parent and an unsigned child).  Absent clear 
instructions, I fear that resolvers will get this detail wrong, 
potentially leading to spurious validation failures.

Rather than going into that detail, I propose that we choose the path 
of simplicity and eliminate the delegation-only requirement.

-- Sam

On Wed, 22 Mar 2006, Sam Weiler wrote:

>> This isn't a special case.  This happens in non-opt-in DNSSEC. What do you 
>> think happens there?
>
> clearly told resolvers how to distinguish between the case I described and 
> the case where is there isn't a delegation (and the A record is in the parent 
> zone).
>
> Would you walk through the process (whether from rfc4035 or 4.2 of this 
> document) for this example?
>
> Does the resolution process then go on to prove that there's a delegation to 
> child.example?  If not, how do we separate this case from the one where this 
> is no delegation to child.example (which, per the quoted text, MUST generate 
> a validation failure)?

---

From: David Blacka <[email-masked]>
Date: Sun, 26 Mar 2006 15:22:22 -0500

On Mar 25, 2006, at 11:39 PM, Sam Weiler wrote:

> Last week, David and I talked more about opt-in section 4.2.1,  
> which results from the delegation-only requirement this WG imposed  
> on opt-in some time ago.
>
> that fall within an Opt-In NSEC record's span."  We concur (I  
> think) that neither this document nor DNSSECbis specifically tell a  
> resolver how to do that, and, in particular, that it may need to  
> explicitly look for a delegation if it receives unsigned records  
> from within an opt-in span (which might happen if a single server  
> is authoritative for both the opt-in parent and an unsigned  
> child).  Absent clear instructions, I fear that resolvers will get  
> this detail wrong, potentially leading to spurious validation  
> failures.

Sam is specifically arguing that a validator will have difficulty  
telling the difference between a non-delegation covered by an opt-in  
span and a response coming from an insecure subzone (with a  
delegation covered by an opt-in span) on the same authoritative  
server.  Essentially, getting confused when the validator doesn't  
directly see the delegation.

> Rather than going into that detail, I propose that we choose the  
> path of simplicity and eliminate the delegation-only requirement.

I'm not sure that is the simplest path.  A seemingly great number of  
questions about how opt-in works are essentially answered with "that  
can't happen because it is delegation-only".  Like, for instance, can  
you opt out the zone apex (no) ? can you opt-out a wildcard (no) ?   
So we would have to replace "delegations only" with a possible more  
complex set of rules.

Instead, I suggest that I add a sentence or two describing that, in  
some cases, the validator may not see the insecure delegation, and  
thus must probe to discover the delegation in such a way that it is  
clear that it is an insecure delegation.  I.e., by issuing a query  
for possible-delegation/IN/NS to the parent.  Or, alternately, just  
warning future implementors that this case exists and thus to handle  
it as they see fit.

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 27 Mar 2006 16:59:16 +0200

On Mar 26, 2006, at 10:22 PM, David Blacka wrote:

> I'm not sure that is the simplest path.  A seemingly great number  
> of questions about how opt-in works are essentially answered with  
> "that can't happen because it is delegation-only".  Like, for  
> instance, can you opt out the zone apex (no) ? can you opt-out a  
> wildcard (no) ?  So we would have to replace "delegations only"  
> with a possible more complex set of rules.
>

Besides, the delegation only requirement the result of endless and  
heated debates about the change in the security model that we had  
when opt-in first came to the table.

I prefer we do not try to relive that era.

<no hat>
> I.e., by issuing a query for possible-delegation/IN/NS to the parent.

Would querying for a DS at that parent work? I would think that that  
would be the regular fall back when trying to build a chain of trust?

</no hat>

--Olaf

---

From: David Blacka <[email-masked]>
Date: Mon, 27 Mar 2006 11:35:38 -0500

> I prefer we do not try to relive that era.

Exactly.

> Would querying for a DS at that parent work? I would think that  
> that would be the regular fall back when trying to build a chain of  
> trust?

Depends on what you mean by "work" :)  I think you can certainly not  
generate false validation failures, but it would be difficult to  
enforce delegation-only.

Essentially, in order to enforce the MUST in section 4.2.1 of opt-in,  
the validator MUST see the delegation in order to distinguish the  
case from an non-delegation-only opt-in zone.  The DS query to the  
parent won't show that.

Personally, I think that using the DS query is fine, as I don't see  
any actual security value from the validator actually enforcing  
delegation-only in this case.  However, it doesn't match what the  
document says.

> </no hat>

- --

---

From: Sam Weiler <[email-masked]>
Date: Mon, 27 Mar 2006 14:52:42 -0500 (EST)

> would be the regular fall back when trying to build a chain of 

I'm not certain, but it could only work if you either were lucky 
enough to guess the proper name of the delegation point or tried them 
all (remembering that the parent could have a multi-label delegation). 
This is one of the reasons why the underspecification in 4.2.1 worries 
me.

FWIW, I do concur with David's statement: "I don't see any actual 
security value from the validator actually enforcing delegation-only", 
which is one of the reasons I advocated removing the delegation-only 
restriction rather than add more complexity to the validator and the 
document.

-- Sam

---

From: David Blacka <[email-masked]>
Date: Mon, 27 Mar 2006 15:35:41 -0500

On Mar 27, 2006, at 2:52 PM, Sam Weiler wrote:

>> that would be the regular fall back when trying to build a chain  
>> of trust?
>
> enough to guess the proper name of the delegation point or tried  
> them all (remembering that the parent could have a multi-label  
> delegation). This is one of the reasons why the underspecification  
> in 4.2.1 worries me.

The issue here isn't that you would have to guess the name of the  
delegation point.  In normal 4035 DNSSEC, you would have to try them  
all, or at least, try them until you got an actual insecure delegation.

The issue is that the response to the DS query doesn't really tell  
you if that name has a delegation or not.  That is, the response  
looks the same if there is a delegation or just some other insecure  
RRSet.

However, in general, I think that this is OK, even if it doesn't  
comply with the MUST in 4.2.1 of opt-in.  I think this because, while  
it would allow some forms of non-delegation-only zones to actually  
work (assuming the authoritative nameserver knew how to serve it  
correctly), it wouldn't expose new corner-cases in the zone itself  
(such as: can the SOA be opted-out? can a wildcard?)

> security value from the validator actually enforcing delegation- 
> only", which is one of the reasons I advocated removing the  
> delegation-only restriction rather than add more complexity to the  
> validator and the document.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 29 Mar 2006 14:17:18 +0200

On Mar 27, 2006, at 10:35 PM, David Blacka wrote:

> comply with the MUST in 4.2.1 of opt-in.  I think this because,  
> while it would allow some forms of non-delegation-only zones to  
> actually work (assuming the authoritative nameserver knew how to  
> serve it correctly), it wouldn't expose new corner-cases in the  
> zone itself (such as: can the SOA be opted-out? can a wildcard?)

But this would be an argument for a "SHOULD" instead of a "MUST" in  
4.2.1 or at the least some wording about this corner case and an  
explanation that security properties would not change (you cannot  
make something insecure that is in fact secure).

I think we should address this now we know of it. Maybe not nibble it  
to death (we are talking about an 'experiment' here).

no hats,

--Olaf