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

From: Sam Weiler <[email-masked]>
Date: Wed, 8 Mar 2006 13:19:38 -0500 (EST)

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

It is _not_ just experimenting with new algorithms, nor is it for 
experiments with non-DNSSEC parts of the protocol.  We're talking 
about experimenting with DNSSEC flavors, extensions, and bad ideas. 
The unknown algorithm tells DNSSEC-aware resolvers that aren't part of 
the experiment "you don't know what's going on here -- just ignore any 
DNSSEC bits you see in this zone and treat it as unsigned".

Classic examples include NSEC3 and opt-in.  We MIGHT have been able to 
use this method to test DS (RFC3658).  We could also use this method 
to signal a change in typecodes (RFC3755), though the new typecodes 
would probably be used as part of some larger experiment (like NSEC3).

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

In general, no.  There is only one zone.  It may use no DNSSEC, 
"standard" DNSSEC, or some "experimental" DNSSEC.  It may be that the 
extension is backwards compatible, allow a zone to be validated by 
both "standard" and "experimental" resolvers at the same time, but I 
imagine that to be an exceptional case.

Example: a zone could publish (and return) both NSEC and NSEC3 RR's, 
potentially allowing it to be validated by both "standard" and "NSEC3" 
resolvers.  But the mechanics of doing that might prove challenging.

So the text is a reasonable generalization.

-- Sam

--
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: David Blacka <[email-masked]>
Date: Wed, 8 Mar 2006 19:05:25 +0000

On Mar 8, 2006, at 5:50 PM, Thomas Narten wrote:

>>> 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.
>
> High-level, coming from someone who may not be terrible DNSSEC savvy.

No problem, your comments are still appreciated ;)

> 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.
>
> 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"?

This document isn't about experimenting with anything in particular.   
It is describing a methodology for doing an experiment safely, not  
describing a particular experiment.

As for what exactly is being tested: section 3 is an attempt to  
define the basic boundaries of what sorts of things may be tested.   
However, I suspect that section 3 is too clumsily stated.

> (e.g., a past proposal) that could be tested using this scheme.

Like draft-ietf-dnsext-dnssec-opt-in-08 ?

Since this is just documenting an approach for shielding unaware  
DNSSEC validators from non-backwards-compatible changes to DNSSEC it  
didn't seem appropriate to point to a particular experiment.

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

Fair enough.  How about reducing to just the last sentence?

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

Yes, that sentence doesn't make sense, and your modification works fine.

>>    DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment- 
>> a.example.com" is
>>    an alias of DNSSEC algorithm 5 (RSASHA1).
>
> same issue.

Ok.

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

No, that isn't the intent.  The intent is to mandate that a resolver  
that understands the experimental semantics (e.g., the opt-in flag)  
only treats the response as signed if and only if the zone was signed  
only by one or more of the private algorithms.

Or, in other words, the resolver must treat the zone as unsigned,  
even though it could  treat the zone as signed.

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

Well, technically no.  The existing specs only use "SHOULD".  The  
assertion in section 4 is essentially pointing out that while the  
specs say "SHOULD", it is effectively (or maybe just believed to be)  
a MUST.  So this is basically a caveat that while this technique is  
*believed* to work, it might not.

OTOH, you can basically read this as "there may be bugs out there",  
which is, of course, obvious.

>> experimental
>>        zone.

No, it can't.

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

Really?  I'm using "version" in the sense of protocol versioning.   
Does that not make sense?  That sentence is not strictly necessary,  
so I'll delete it if it is unclear.

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

Well, to be precise, it only RECOMMENDS the use of private  
algorithms, it does not require them.  And, if they aren't used, then  
IANA would need to allocate DNSSEC algorithm numbers.

So, Thomas, are you suggesting that the document REQUIRE use of  
private algorithm identifiers?

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

---

From: David Blacka <[email-masked]>
Date: Mon, 13 Mar 2006 15:51:29 -0500

> I don't know the difference between "technical" and "practical"

It has occurred to me after a private conversation that it might be  
useful to explain what I was trying to get at here, so maybe someone  
can suggest better language.

In this paragraph, the alluded-to "practical" reasons have all  
actually been pretty must just one practical reason: If we start work  
on X, then we will delay [widespread] deployment of DNSSEC.  That is,  
it is trying to say that an experimental methodology is useful in the  
sense that it provides a way around that practical, but not  
technical, sentiment.

I don't particularly think that this is a useless concept to convey,  
but I also recognize that it isn't strictly necessary either.