Subject: Re: private algorithms and the DS record

From: David Blacka <[email-masked]>
Date: Mon, 20 Dec 2004 10:31:17 -0500

On Dec 17, 2004, at 10:54 AM, Olaf M. Kolkman wrote:

> Are you refering to algorithm id clashes?

yes.

Private algorithms are identified with an algorithm number (253 or 254)
and an additional DNS name or OID.  When you are looking at a DNSKEY or
RRSIG, you can figure out exactly what the algorithm name is by looking
at the number, seeing that it is 253, then looking at the beginning for
the key data or signature data and parsing a DNS name.

Nobody has implemented this that I know of, but it looks easy enough.

HOWEVER, when the resolver is following a delegation, it 1) looks for
the presence or absence of the DS set.  If present, it makes sure that
it understands at least one of the algorithms presented in the DS
record.  BUT, it cannot tell if "253" refers to a private algorithm it
has heard of or some other private algorithm, because there are NO
INSTRUCTIONS for putting the private key DNS name or OID in the DS
record anywhere.  Therefore, one has to assume that it is not present.
Thus, the only information that the resolver has at that point in the
validation process is that the DS record is using *some* private
algorithm, but it cannot tell which one.

Basically, all I am pointing out is that private algorithm identifiers
need to be handled everywhere algorithm numbers appear.  And the DS
record is missing information about to handle private algorithms.

It is true that, if the validator goes on to the subzone and fetches
the DNSKEYs, it can match the DS to the DNSKEY and actually find out.
BUT, the way protocol-09 is written, that isn't how validators are
expected to work.

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

--
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: Edward Lewis <[email-masked]>
Date: Mon, 20 Dec 2004 16:40:16 -0500

At 15:17 -0500 12/16/04, David Blacka wrote:
>I was thinking about the use of private algorithms in DNSSEC the other day,
>and it struck me that they might not, strictly speaking, work.

>Fair enough, but there are no instructions for the DS record.  So how would a
>resolver be able to distinguish between a known private algorithm from an
>unknown private algorithm from the delegation?

>I.e., it is expected that a DNSSEC validator would be able to make the
>determination that it does or does not support any of the algorithms directly
>from the DS set.  As soon as a DNSSEC validator knows about one private
>algorithm (per scheme), it suddenly cannot make this determination.
>
>Or am I missing something?

I'll start with what might be, strictly speaking, a dumb question.

Why can't a verifier do this/What happens if this is what is done:

    Get the DS set for X and validate it with parent's algorithms
    Toss out all the DS records for unknown algorithms it finds in the set
    (Toss out = remove from further consideration)
    Finds one (to make this simple) last DS - for a 'private' algorithm
    Get the DNSKEY set for X w/o validation
    Finds the lone corresponding DNSKEY and pulls out the private alg name
    Looks to see if the private alg name is one it understands

Course, here's where the problems begin:

1) If the private alg name is one not understood, there's no way to 
validate that the received DNSKEY set for X is genuine.

2) If the private alg name is understood and the DNSKEY set fails to 
validate then you have dubious data

3) If the private alg name is understood and the DNSKEY set passes 
validation you are in luck.

The problem is with #1 and #2.  You can't decide if the received data 
is genuine (and you therefore ought to proceed as if you can't 
validate the data) or if the data is sub'd in for a set that oughta 
fall into category #3.

E.g., let's say verifier and signer know Godot's Algorithm, called 
"godot.algorithm" in a private-algorithm public key.  I ask for 
"www.dave.example."  and along the way get the DS set for 
dave.example.

So the next thing I expect to hear is a DNSKEY set for dave.example 
sent from dave.example, but instead Bert is off in the corner 
sniffing my wireless and transmits his "version" of the DNSKEY set 
for dave.example., with a private algorithm called "ernie.algorithm" 
in it.

I'll hear Bert's version and process it before the true version gets 
into the airwaves.  Given careful crafting of the private algorithm, 
I can be duped into believing that Dave's Algorithm isn't in use, but 
Ernie's Algorithm is.  But since I don't know Ernie's Algorithm, I 
give up.

Even if the airwaves will soon send the true DNSKEY set my way, why 
after thinking may I should give up for legitimate reasons, would I 
continue wait for Godot?  ("It's a joke son." - Foghorn Leghorn.) End 
of e.g.

It seems to me to be that A) private algorithms are hosed or B) the 
DS2 RRSet includes the sub-algorithm field (the name of the private 
algorithm).  Well, those are my two first approximations - maybe 
there's a way to squeeze the private alg name into the hash in the DS 
for private algorithms before it's too late.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: David Blacka <[email-masked]>
Date: Mon, 20 Dec 2004 23:20:26 -0500

Edward Lewis wrote:

> The problem is with #1 and #2.  You can't decide if the received data is 
> genuine (and you therefore ought to proceed as if you can't validate the 
> data) or if the data is sub'd in for a set that oughta fall into 
> category #3.

Once again, Ed dazzles me with his insight.  I had not yet considered 
the security implications of this issue, only the asymmetry of it.

Just to summarize: Ed has shown that a zone signed only with a known 
private algorithm (and any number of unknown algorithms) could be made 
to appear (erroneously) insecure via a MitM attack.

> It seems to me to be that A) private algorithms are hosed or B) the DS2 
> RRSet includes the sub-algorithm field (the name of the private 
> algorithm).  Well, those are my two first approximations - maybe there's 
> a way to squeeze the private alg name into the hash in the DS for 
> private algorithms before it's too late.

Well, if we don't fix it, then yes, I believe that private algorithms 
are hosed.  As for B), I don't think we need to define a DS2, we need 
merely to define the same rule for DS records as is defined for DNSKEY 
and RRSIG.

For instance, we could modify the second sentence of the first paragraph 
of records-11, Appendix A.1.1 from:

    The public key area in the DNSKEY RR and the signature area in the
    RRSIG RR begin with a wire encoded domain name, which MUST NOT be
    compressed.

to

   The public key area in the DNSKEY RR, the signature area in the RRSIG
   RR, and the hash area in the DS RR begin with a wire encoded domain
   name, which MUST NOT be compressed.

Plus a similar transformation in the next paragraph for the OID case, 
assuming that it isn't too late to modify the document before RFC.

That would give the DS as much attention as anything else with respect 
to private algorithms, in any case.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 21 Dec 2004 12:15:39 +0100

On Mon, 20 Dec 2004 23:20:26 -0500

>  of records-11, Appendix A.1.1 from:
(...)

Hmmmm.... this hurts a bit. 

We have a choice;

- We send in a note to the RFC editor, now or during 48-hours; that is
  if the WG consents on this issue.  (this is a security bug that was
  not covered earlier).

- We let the RFCs be published and write a small I-D that updates the
  documents. 

Whatever we do we have a problem of deployed code not knowing of
this. I currently think the first choice is more elegant.

Please spend some time on reviewing this issue and its solution, it is
important enough!

-- Olaf

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Dec 2004 09:17:14 -0500

>- We let the RFCs be published and write a small I-D that updates the

I'd prefer the first - I find clarification documents tiring.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 21 Dec 2004 10:49:03 -0500 (EST)

> validate that the received DNSKEY set for X is genuine.

I'm confused.  Doesn't the DS hash already cover the name of the
algorithm, which is carried in the DNSKEY?  The validator doesn't need
to check the RRSIG(DNSKEY), just match the DNSKEY to the DS.  Yes,
someone could substitute in a DNSKEY with a different private
algorithm name, but, unless these cryptographic hashes aren't worth
the money we're paying for them, the DS won't match whatever the
attackers generate, right?

In other words, I think Ed's validator todo list is sufficient (which
adds the "if it's a private algorithm, get the DNSKEY and see if you
understand it" steps).

> maybe there's a way to squeeze the private alg name into the hash
> in the DS for private algorithms before it's too late.

I don't think this is needed.

As for updating the docs, I also prefer an RFC Editor note rather than
a separate doc.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Dec 2004 11:18:12 -0500

At 10:49 -0500 12/21/04, Samuel Weiler wrote:

>Doesn't the DS hash already cover the name of the
>algorithm, which is carried in the DNSKEY?

There is that safety net, yes.  Maybe all hope is not lost.

>The validator doesn't need
>to check the RRSIG(DNSKEY), just match the DNSKEY to the DS.

One factoid that's been bandied about is that the RRSIG(DNSKEY) 
provides two functions.  It enables the KSK/ZSK model of key 
management.  It also provides a time-limiting/revocation-like 
function, i.e., if there is no RRSIG(DNSKEY) then the DNSKEY set is 
worthless to validation.  If you can't make heads or tails of the 
key's algorithm, the key is of no value to you, the fact that this 
makes the RRSIG(DNSKEY) for it also unintelligible is unimportant.

>attackers generate, right?

I suppose that's the case.  I wonder - if you have a 2048 bit key for 
a private algorithm and a 160 bit hash, I'd be pretty free to find a 
2048 bit sequence to put at the end of a domain name to cook up a 
result.  For the mathematicians, just how good is SHA-1.

(Yes, I know, here we go again with the crypto fans touting how good 
SHA-1 is. ;))

---

From: Alex Bligh <[email-masked]>
Date: Tue, 21 Dec 2004 16:51:05 +0000

> As for updating the docs, I also prefer an RFC Editor note rather than

(From a position of relative ignorance) yes I agree - assuming we are
confident we have infact bottomed the problem out as the worst thing
to do would be to half fix it.

Alex

---

From: David Blacka <[email-masked]>
Date: Tue, 21 Dec 2004 12:27:42 -0500

> to do would be to half fix it.

Perhaps I am now suddenly confused.  What is "half fix it"?

Let me summarize this issue as I see it:

1) I pointed out an issue of symmetry: in this one case, a validator 
cannot make the same decision at the same algorithmic point as it can 
without private algorithms.  That is, it cannot decide to treat the 
subzone as unsigned from the DS set alone, it must fetch the DNSKEY to 
find the full name of the algorithm.  I see this as an implementation 
problem.  Something that might work, but is an unnecessary complication, 
and a complication that isn't clearly visible from the documents.

2) Ed pointed out a possible security problem.

3) Sam argued that this security problem (if it exists) would be hard to 
exploit.

Let's approach this issue from the opposite direction.  Is there any 
reason NOT to prepend the private alg. name to the DS hash?  Was the 
fact that the DS wasn't mentioned in the private algorithm appendix ON 
PURPOSE?

I am personally of the opinion that the fact that the DS was omitted was 
just an oversight, due to the fact that no one really examined private 
algorithms during the main review process.  I am of the opinion that NOT 
fixing this means, at the very minimum, that private algorithm support 
will be harder than necessary to implement in the validator.  It *may* 
mean that private algorithms are unusable or at least unsafe.

And I am unsure where the concept that putting the private algorithm 
label in the DS record only "half" fixes the problem comes from.  Or why 
it would be seen as any more of a hack in DS than in DNSKEY or RRSIG.

If, as I suspect, this was a simple oversight, then of course an RFC 
Editor note is the correct approach.

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

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 21 Dec 2004 12:56:06 -0500

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka
>

It was an oversight.  Private algorithms were not really brought up enough
during the rewrite process.

Scott

---

From: Alex Bligh <[email-masked]>
Date: Tue, 21 Dec 2004 18:14:04 +0000

> Perhaps I am now suddenly confused.  What is "half fix it"?

I'm not pointing out any great hole and I'm not saying what you propose
half fixes it. I am just saying if we rushed into getting EFC Editor to put
in a note to the effect suggested, and a short time later Ed came up with
another equally startling revelation saying "oops we didn't fix that hole
completely" we'd look a bit silly (and worse have rather confused
documentation).

The advantage of the I-D process is that it gets more peer review,
so it would be good to know, if we are going to go the RFC-Editor process,
that everyone thinks we've really fixed the hole, and that there's
no/little change peer review is going to point out a problem with the
proposed solution.

FAOD, from my ill-informed standpoint, fixing it as described seems the
right thing to do.

Alex

---

From: Rob Austein <[email-masked]>
Date: Tue, 21 Dec 2004 13:18:31 -0500

> and a complication that isn't clearly visible from the documents.

I think what you've detected is an optimization that can't be
performed in the case of private algorithms.  The original purpose of
the algorithm check on the DS RRset was to defend against algorithm
downgrade attacks (your points 2 and 3).  I do not see it as a big
deal that one has to retrieve the child's apex DNSKEY RRset before one
can figure out whether one really understands the algorithm in use.

The private algorithms are specified as subtypes of a subtype.  You
should expect them to be a horrible mess.

> 3) Sam argued that this security problem (if it exists) would be hard to 

I think that Sam and Scott have demonstrated that this is not in fact
a serious problem, since the DS hash covers the algorithm ID.

There may be an algorithm downgrade attack issue if somebody uses two
separate private algorithms in the same zone.  Maybe not.  Haven't
analyzed it in detail.  Am not convinced we should be losing sleep
over it.

> fact that the DS wasn't mentioned in the private algorithm appendix ON 

If I understand what you're proposing, it would special-case the
private algorithm subtype, ie, the DS RR would now be doing special
voodoo for the private algorithm subtypes.  The situation is not
equivilent to the situation with DNSKEY and RRIG -- in the latter
cases, the special-case voodoo was inserted into a field that's
algorithm-specific in any case (key material or sig material,
respectively).  In the DS case, if I understand you correctly, you're
proposing to insert the special-case voodoo into a field that's the
same for every (signature) algorithm (hash of the key material).

I don't think we should do this to the DS RR.  It already hashs the
private algorithm identifier information as part of the key material,
that should suffice.

So, to answer your question, while I don't think there was a concious
decision here (don't think anybody thought much about it), I think the
algorithm as specified is correct.

If you do manage to convince the WG to change this, we'll probably
need to do the equivilent of TCR to the private algorithm subtypes.

--Rob

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 21 Dec 2004 16:00:29 -0500 (EST)

> Is there any  reason NOT to prepend the private alg. name to the DS
> hash?

I concur with Rob: this adds unnecessary ugliness to the DS RR, and is
likely a backwards-incompatible change.  I don't want to have to dust
off 3755 and wait for IANA again.

> Was the fact that the DS wasn't mentioned in the private algorithm
> appendix ON PURPOSE?

Concur with Scott and Rob: there was no particular consideration given
to private algorithms.  If there had been, I still doubt we would have
changed anything.

-- Sam

---

From: David Blacka <[email-masked]>
Date: Tue, 21 Dec 2004 16:18:57 -0500

> off 3755 and wait for IANA again.

Backwards-incompatible with what?

> to private algorithms.  If there had been, I still doubt we would have

The text of protocol-09 section 5.2 does not support this postion.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 21 Dec 2004 23:15:35 +0000

Edward Lewis wrote:
> One factoid that's been bandied about is that the RRSIG(DNSKEY) provides 
> two functions.  It enables the KSK/ZSK model of key management.  It also 
> provides a time-limiting/revocation-like function, i.e., if there is no 
> RRSIG(DNSKEY) then the DNSKEY set is worthless to validation.  If you 
> can't make heads or tails of the key's algorithm, the key is of no value 
> to you, the fact that this makes the RRSIG(DNSKEY) for it also 
> unintelligible is unimportant.
> 
> I suppose that's the case.  I wonder - if you have a 2048 bit key for a 
> private algorithm and a 160 bit hash, I'd be pretty free to find a 2048 
> bit sequence to put at the end of a domain name to cook up a result.  
> For the mathematicians, just how good is SHA-1.
> 

Is this my cue? The work factor for finding such a cooked up result is 
huge, i.e. around 2^159. Yes, there are many 2048 bit sequences that'll 
work, but finding one will take you a _very_ long time. Impossibly long.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Dec 2004 19:58:05 -0500

At 23:15 +0000 12/21/04, Ben Laurie wrote:

>Is this my cue? The work factor for finding such a cooked up result is huge,
>i.e. around 2^159. Yes, there are many 2048 bit sequences that'll work, but
>finding one will take you a _very_ long time. Impossibly long.

Right on the mark.  I suppose finding a sequence that matches the 
footprint and hashes the same is even more to ask.  Exit stage left.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Rob Austein <[email-masked]>
Date: Wed, 22 Dec 2004 00:01:48 -0500

> Backwards-incompatible with what?

At least one of us is confused.

If I understood you correctly, you proposed that the DS RR "Digest
Field" (-records-11 5.1.4), which currently holds a digest calculated
on the same field of the corresponding DNSKEY RR regardless of the
signature algorithm, should be changed to include a second copy of the
private algorithm identifier as a special case for the private key
subtypes of the DNSKEY RR.  This would be an incompatable change to
the content of the DS RR: currently deployed code based on the current
specs would have to be changed, since otherwise digests would never
match for the private key subtypes.

Please note that, if you follow the definitions in -records 5.1.4,
2.1.1 through 2.1.4, and A.1.1, the private algorithm subtypes (253
and 254) -already- include the private algorithm identifier (DNS name
for subtype 253, OID for subtype 254) in the public key field (2.1.4),
which is of course already included in the hash (5.1.4).  You appear
to be proposing that we include a -second- copy of this private
algorithm identifier in the DS hash, for reasons that escape me.

Or perhaps you're proposing to include the raw private identifier
algorithm itself rather than its hash, and the hash field of the DS RR
is now to contain the concatenation of the private algorithm
identifier and the hash, again special-cased just for the private
algorithm subtypes, which is again not backwards compatible.  If this
is what you meant, the case for it is a bit more understandable, but
it's still unnecessary, since that identifier is already an input to
the hash and is thus already available for you to use without
requiring a non-backwards compatible change.

Yes, there is deployed code, at least three implementations if I
recall correctly (nsd, bind9, Net::DNS::SEC, perhaps others I've
forgotten).  Yes, we could change all of them if we had to, but I
don't think you've yet demonstrated any real need to do so.

At least one of us is confused.  Perhaps it's me.

> The text of protocol-09 section 5.2 does not support this postion.

Hmm?  -protocol 5.2 talks about what happens if one doesn't support
any of the algorithms listed in the DS RRset.  In the case of private
algorithms, yeah, one has to retrieve the child's zone's apex DNSKEY
RRset and compute the DS hashes in order to figure out precisely which
algorithms are listed in the DS RRset.  So what?  Please show me where
it states that the validator is not allowed to retrieve the DNSKEY
RRset if it needs that RRset in order to figure out whether it
supports the algorithms listed in the DS RRset.  It has to retrieve
that same DNSKEY RRset anyway if it does understand any of the
algorithms, so what's the issue here?

As stated in an earlier message, I think you've found a place where an
obvious optimization doesn't work for private algorithms, so one has
to do it the slow way.  Subtyping sure is a pain, isn't it?

--Rob

---

From: David Blacka <[email-masked]>
Date: Wed, 22 Dec 2004 09:35:25 -0500

> There is that safety net, yes.  Maybe all hope is not lost.

There is still potential for a security problem, here, I think.

If an implementation pulls the private algorithm name from the DNSKEY 
and eliminate the DNSKEY and DS before actually computing the SHA1 hash 
of the DNSKEY.

This seems like a natural thing to do.

Certainly, there is a safer way to handle this, but how will a future 
implementer be aware of the issue?  By reading the namedropper archives?

---

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Dec 2004 10:17:32 -0500

At 9:35 -0500 12/22/04, David Blacka wrote:
>If an implementation pulls the private algorithm name from the DNSKEY and
>eliminate the DNSKEY and DS before actually computing the SHA1 hash of the
>DNSKEY.

I'm not following...(maybe I'm context switching too much)...can you elaborate?

>implementer be aware of the issue?  By reading the namedropper archives?

Sure - I have a copy of the DNSSEC WG archives on my disk at all times...;)

---

From: David Blacka <[email-masked]>
Date: Wed, 22 Dec 2004 10:37:26 -0500

> I'm not following...(maybe I'm context switching too much)...can you 

Sure.  Remember that, in the absence of private algorithms the implied 
algorithm is:

1) get a referral containing a DS set.
2) for each DS, check the algorithm.  If you do not recognize the 
algorithm, remove it from consideration.
3) if there are still DSs in consideration, then the subzone must be 
signed. if there aren't DSs in consideration (i.e., no supported 
algorithms), consider the zone unsigned (or follow local policy, whatever)
4) fetch the DNSKEYs from the subzone, match DSs to DNSKEYs.

In the presence of private algorithms, the temptation might be to 
replace step 2 with:

2) for each DS, check the algorithm.  If you understand a private 
algorithm, and one of the DSs uses a private algorithm, fetch the DNSKEY 
   set from the child, find the correct key via algorithm and keyid, 
pull the private algorithm name and continue as before.

I.e., do the minimum amount of work to satisfy the requirements of step 2.

Where the safe thing to do is: .. find the correct key via algorithm and 
keyid, make certain the DS hash matches the DNSKEY key ..

The difference between doing the safe thing and not is currently an 
awareness of this safety issue.  Right now, the only way a future 
implementer would be aware of this issue (and how to handle private 
algorithm, period, for that matter) is to either read the namedroppers 
archives, or to recreate this analysis.

Maybe it will never come up.  Or maybe all implementers of DNSSEC will 
have read this thread when it was posted.

---

From: David Blacka <[email-masked]>
Date: Wed, 22 Dec 2004 12:13:30 -0500

> At least one of us is confused.

I think that now we are getting somewhere.

> match for the private key subtypes.

Why would a validator ever match a DS with an unknown algorithm to a DNSKEY?

My central assumption here is that while there is deployed DNSSEC code, 
there is no deployed DNSSEC code that thinks it understands any private 
algorithm.

So, with the currently deployed base, what difference does it make that 
a DS with a private algorithm would never match a DNSKEY?  It could 
never be used anyway.

If, in the future, implementations add private algorithm support, why 
wouldn't they be able to understand this extension?

> algorithm identifier in the DS hash, for reasons that escape me.

Re-read section 5.2, and tell me how to reconcile the advice given there 
with how private algorithms are defined.  You might want to re-read my 
first few posts on this subject.

> algorithms, so what's the issue here?

To elaborate on my statement:  I disagree that we would not have changed 
*anything*.  At the very least, this corner case would have been 
mentioned somewhere in the document (either section 5.2 or A.1.1, I expect).

My issue is not that the behavior you suggest is disallowed, but that it 
also isn't mentioned anywhere.  How is a future implementer supposed to 
know what the issue is here?

Keep in mind that the case under discussion is about when the only 
difference between the DS set containing zero supported algorithms and 
one is a private algorithm.  If the DS record contains one DS with a 
private algorithm and one DS with algorithm 5, the whole issue will 
never come up.

> to do it the slow way.  Subtyping sure is a pain, isn't it?

It is certainly more of a pain when the subtyping is applied inconsistently.

I am in no way wedded to the idea of modifying the format of the DS RR. 
  It just looks like the easiest way to solve the problem that I am 
concerned about.

My central issue here is that I am concerned that, if someone were to 
implement private algorithms, they would not, in the final analysis, work.

My original point was the conflict between how private algorithms are 
defined to work in Appendix A.1.1 and the text in section 5.2.  I could 
requote it all here, but I think I will just point you all back to my 
original message starting this thread.  The gist of it is that section 
5.2 implies that a validator makes the decision about whether or not to 
treat the child zone as signed or not from the DS set alone.

That this technique is, in fact, an optimization of a slower algorithm 
may, in fact, be true, but this slower algorithm is *not* *documented*.

Maybe I'm just too pessimistic here.  When I see something that is 
unclear and confusing to me, I assume that it will also be unclear and 
confusing to others.  Maybe it won't.

I see four possible resolutions here:

1) DS records are modified to contain the private algorithm name, 
allowing the validator algorithm to work the same for public and private 
algorithms, or
2) The need and algorithm for fetching the private algorithm name from 
the DNSKEY in a safe manner is documented somewhere (another RFC or 
additional text), or
3) private algorithms are deprecated, or
4) everyone else decides that the current text is clear enough, there is 
no need to change anything, we are fairly sure that future 
implementations of private algorithm support will work just fine, thank 
you very much.

Any of the above resolutions are acceptable, I think.

---

From: Rob Austein <[email-masked]>
Date: Wed, 22 Dec 2004 14:03:16 -0500

> Why would a validator ever match a DS with an unknown algorithm to a

If the validator knows that it supports at least one private
algorithm, it needs to figure out whether it supports the particular
private algorithm(s) in question.  The information that the validator
needs to do this is available, but it's not all in the DS RRset: some
of it is in the DNSKEY RRset, so the validator needs to retrieve and
examine the DNSKEY RRset too.

> My central assumption here is that while there is deployed DNSSEC
> code, there is no deployed DNSSEC code that thinks it understands
> any private algorithm.

Current implementations think that they know how to generate the DS
hash for any DNSKEY RR.  You propose to break that.

Whether there are any current implementations of private
algorithms...I'm not aware of any, but, by definition, nobody would
have to tell either you or me if there are any, would they?

> So, with the currently deployed base, what difference does it make
> that a DS with a private algorithm would never match a DNSKEY?  It
> could never be used anyway.

Doing it my way, the code currently in the field could support this
with no changes.  Implementations that don't support any private
algorithms at all can bail out based just on the algorithm number from
the DS RRset; implementations (if any) that do support private
algorithms can retrieve the DNSKEY and check the private algorithm
identifier of the DNSKEY that matches the DS hash.

Doing it your way, everybody has to know how to do the new DS
calculation algorithm.  I still don't see why we need this.

> If, in the future, implementations add private algorithm support,
> why wouldn't they be able to understand this extension?

If we change the protocol to include this extension, of course they
would, but it's not necessary.

> > 2.1.1 through 2.1.4, and A.1.1, the private algorithm subtypes
> > (253 and 254) -already- include the private algorithm identifier
> > (DNS name for subtype 253, OID for subtype 254) in the public key
> > field (2.1.4), which is of course already included in the hash
> > (5.1.4).  You appear to be proposing that we include a -second-
> > copy of this private algorithm identifier in the DS hash, for
> > reasons that escape me.
> 
> Re-read section 5.2, and tell me how to reconcile the advice given
> there with how private algorithms are defined.  You might want to
> re-read my first few posts on this subject.

I've read all of this, more than once.  You still haven't answered my
question: please show me the text that forbids the validator from
retrieving the DNSKEY RRset as part of figuring out whether it
supports the agorithms listed in the DS RRset.  -protocol 5.2 doesn't
specify -how- the validator performs this check.  You appear to be
assuming that the validator is only allowed to do a byte equality test
on the algorithm number and is not allowed to think harder if the
algorithm number is itself subtyped.  No, wait, you do want it to be
allowed to think harder if it's subtyped, because if it's one of the
private algorithm numbers you want it to do an extra check.  Ok, so
why is your extra check (that requires a protocol change) better than
mine (which doesn't)?  I don't get it.

Please try re-reading section 5.2 yourself, ok?  :)

> To elaborate on my statement: I disagree that we would not have
> changed *anything*.  At the very least, this corner case would have
> been mentioned somewhere in the document (either section 5.2 or
> A.1.1, I expect).

No doubt, had we had this discussion before approving the documents,
we would have added more text on this subject.  I don't mind writing
more text now either.  I do object to changing the protocol, since I
see no need to do so in this case.

> My issue is not that the behavior you suggest is disallowed, but
> that it also isn't mentioned anywhere.  How is a future implementer
> supposed to know what the issue is here?

Sounds like there's a clarification draft to write. I never much liked
leaving the whacky private algorithm stuff in the base spec anyway,
but the WG said to keep it when the editors asked, so we did.  A
separate draft explaining how to use private algorithms would be fine.
Just please don't change the base protocol.

> difference between the DS set containing zero supported algorithms
> and one is a private algorithm.  If the DS record contains one DS
> with a private algorithm and one DS with algorithm 5, the whole
> issue will never come up.

Right.  So one of two things happens in the case under discussion:

a) The validator knows that it understands zero private algorithms.
   Trivial, give up, we're done.

b) The validator knows that it understands at least one private
   algorithm.  In this case, the validator has to retrieve the DNSKEY
   RRset and check the DS hashes so that it can extract the private
   algorithm identifiers from the DNSKEY RRs corresponding to the
   private algorithm subset of the DS RRset.   Painful, but doable.
   After performing this check, the validator knows whether it
   supports the algorithms listed in the DS RRset or not.  Done.

> I am in no way wedded to the idea of modifying the format of the DS

Good.

> It just looks like the easiest way to solve the problem that I am

Guess we'll have to agree to disagree here.

> My central issue here is that I am concerned that, if someone were
> to implement private algorithms, they would not, in the final
> analysis, work.

I think they would, but the implementor would have to do everything
right, and it's pretty clear that there's some text we should write to
help the implementor do it right.

> My original point was the conflict between how private algorithms
> are defined to work in Appendix A.1.1 and the text in section 5.2.
> I could requote it all here, but I think I will just point you all
> back to my original message starting this thread.  The gist of it is
> that section 5.2 implies that a validator makes the decision about
> whether or not to treat the child zone as signed or not from the DS
> set alone.

You keep saying that, and I keep not seeing it in the text.  Please
show me where it says "from the DS set alone".

> That this technique is, in fact, an optimization of a slower
> algorithm may, in fact, be true, but this slower algorithm is *not*
> *documented*.

Right.  It's implied (well, I think it is, your mileage clearly
varies), but it's not obvious, and I agree that we should fix that.

> unclear and confusing to me, I assume that it will also be unclear
> and confusing to others.  Maybe it won't.

No, you're probably right about that.  It was your proposed solution
(a protocol change) that bothered me, not your problem analysis.

> allowing the validator algorithm to work the same for public and
> private algorithms, or

Please no.

> 2) The need and algorithm for fetching the private algorithm name
> from the DNSKEY in a safe manner is documented somewhere (another
> RFC or additional text), or

Ok with me.  I prefer not to mess around with nontrivial content
changes as RFC Editor note or AUTH48 hacks, so I'd prefer a separate
document.

> 3) private algorithms are deprecated, or

Well that would be ok with me, but the WG wanted to keep this glorp
the last time we asked.

> 4) everyone else decides that the current text is clear enough,
> there is no need to change anything, we are fairly sure that future
> implementations of private algorithm support will work just fine,
> thank you very much.

I think some clarification is in order.  I just don't think it
requires either a protocol change or a last minute change to the
documents we already handed off to the RFC Editor.

> Any of the above resolutions are acceptable, I think.

So I think we agree, except on option (1).

--Rob

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 22 Dec 2004 17:54:49 -0500 (EST)

> allowing the validator algorithm to work the same for public and private

As before, I want to avoid this.

> the DNSKEY in a safe manner is documented somewhere (another RFC or

Excellent choice.  Good catch re: the possible attack if just the
keyid, rather than the hash of the DNSKEY, is compared to the DS --
that needs to be documented.  I'm increasingly fond of a "private
algorithm" doc, but an RFC-Editor note seems practical.  This isn't a
big deal.

> 3) private algorithms are deprecated, or

I'd prefer to leave them in, providing some space for future
experimentation, but I wouldn't object to deprecating them.

> implementations of private algorithm support will work just fine, thank

2 and 3 seem like better choices.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Dec 2004 21:10:57 -0500

At 10:37 -0500 12/22/04, David Blacka wrote:

I'd have to say that it seems that if an implementer does the right 
thing, there isn't a security vulnerability.  Yes, if an implementer 
isn't careful, the code produced may be susceptible to this.

This sounds like an issue with the documentation of the 
specification, not the specification of the protocol.  (It's possible 
that I haven't read all this carefully enough - I apologize.)

>Or maybe all implementers of DNSSEC will have
>read this thread when it was posted.

Over the years I have been infuriated with being told to "go read the 
archives" (either directly or indirectly).  To me, the mailing list 
is like a round-the-table or at-the-blackboard conversation.  It 
isn't permanent, it's not reviewed, it's a "hack" with respect to 
documentation.

(I mean this in the sense that I believe David is being sarcastic 
with the lead-in statement.)

I think the right thing to do is spin up an Informational RFC on the 
topic of private algorithms, beginning with what is in this thread. 
Or perhaps a wider ranging Informational RFC on experiences in 
implementing the validator.

I'm sure that we will find a lot of rough edges in experience with 
the RFCs-to-be.  Remember that these documents are Proposed 
Standards, that means that there is probably more work to do before 
becoming Full Standards.  (Hopefully the work to do is fixing text 
and not fixing code.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 23 Dec 2004 15:26:57 +0100

On Wed, 22 Dec 2004 21:10:57 -0500

>  implementing the validator.

<No Hats>

How about an "implementation note for DNSSEC", I am sure we can come up with other pitfalls?

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 31 Dec 2004 01:16:38 -0500

<chair-hat off>

>during the rewrite process.

But this was discussed in the design process of DS and the feeling
was that Private algorithms where second class citizens
that only role is in testing of new algorithms or some strange
convoluted reasons. Thus there was no need to add complexity to
support them.
Going further back, I remember questioning the text in RFC2065
that included the private algorithm identifiers in SIG RR's and
arguing that key ID was sufficient for selecting the correct key
to test.

If we are going to make any changes I would argue for changing RRSIG
not DS :-).

         Olafur

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 31 Dec 2004 01:25:43 -0500

<Chair-hat-off>
At 12:13 22/12/2004, David Blacka
>1) DS records are modified to contain the private algorithm name, allowing 
>the validator algorithm to work the same for public and private algorithms, or
>2) The need and algorithm for fetching the private algorithm name from the 
>DNSKEY in a safe manner is documented somewhere (another RFC or additional 
>text), or
>no need to change anything, we are fairly sure that future implementations 
>of private algorithm support will work just fine, thank you very much.
>

I see #5
5) Remove special handling of Private Key's in RRSIG, i.e. do the same
thing as in DS and cementing Private algorithm's second class status.

Personally I think 2 is the most appropriate approach if this is
big enough a issue to warrant the attention of the working group.

         Olafur