Re: private algorithms and the DS record

[Edward Lewis <Ed.Lewis@neustar.biz>]

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

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>