Subject: Re: RSA/SHA256

From: Jelte Jansen <[email-masked]>
Date: Thu, 01 Nov 2007 16:03:43 +0100

Doug Barton wrote:
> You guys seem to think that you're making an argument FOR including
> additional hashes, but in my mind you're actually making a case not to
> do it.
> 

actually, i'm trying to see whether there is a way to add algorithms
without adding complexity (other than the knob for the algorithm in the
signers and verifiers). Whether or not we do them now, there seems to be
this thing about algorithm agility lately :)

>>
>> Another reason to do it once is to get it over with in terms of
>> standardization; do we want to repeat this discussion for every hash
>> algorithm that is not completely new? Why go through this process again
>> when some organizations decide that SHA-256 isn't good enough for them
>> and they require 512, when this could have been handled now? It's mostly
>> the same argument, but from a protocol perspective.
> 
> I don't see how adding a lot of hashes now makes adding a new one later
> any easier. (Other than perhaps the fact that implementors will get lots
> of practice writing code for new hashes.)
> 

I wasn't talking about digest algorithms that are yet to be invented.
But if it is for instance foreseen that 512 will be needed later (as
well as 256), it's easier to add them both once than to go through the
I-D and deployment process twice.

In this case the hashes don't differ too much, which is why the can be
grouped together.

> Seriously guys, if there is an overwhelmingly good reason to add all the
> intermediate hashes, please elaborate because I don't see it. "Because
> we can" is NOT a good reason.
> 

Well i could live with 'only' 256 and 512. Or even either one of those,
but i can imagine the use of both. And can probably be convinced of more :)

> 
> You have to resist the temptation to keep tinkering with this thing. If
> you don't think SHA256 is strong enough to last through the early
> implementation cycle while we figure out solutions to problems like
> algorithm rollover, then pick ONE that will be (SHA512?, more?) and then
> let's move on.
> 

Referring to the algorithm agility thing again, i think that if we keep
postponing the problem with every added algorithm (if there even *is* a
problem) we'd just make it harder to find a solution. For instance, if
people invent something brightly magical to use the algorithm field, one
would have to work around the numbers already assigned. Not that i think
that something like that is necessary, or even preferable. But that's
what i'm trying to find out here.

> Ok, rant over. I think I've said pretty clearly what my position is, so
> I'll let others voice theirs.
> 

They seem to be a bit apathetic about it :)

Jelte

--
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: Sam Weiler <[email-masked]>
Date: Thu, 1 Nov 2007 18:03:14 -0400 (EDT)

On Wed, 24 Oct 2007, Jelte Jansen wrote:

> 1) Should this document be written?

Probably.  See answer to #2.

> 2) Should this document specify other hash algorithms as well?

In the interest of keeping the complexity to build new resolvers down 
somewhat, I think we should limit ourselves to only what we think we 
need.  At any time, I would expect that to be no more than "one hash 
algorithm we believe is strong enough" and "one or two more, in case 
we're wrong".  I haven't formed an opinion about exactly which ones we 
need right now, but if we're defining more than two, we're going down 
the wrong path.  Do we need something stronger than SHA1?  Probably. 
Do we need the whole SHA2 suite?  No.  In the absence of a clear sense 
of what to add beyond SHA256, let's stop at SHA256.

> 3) If so, how will we handle the different algorithm/hash types?

I think we should NOT split the field, and I think it's actively 
dangerous to split the registries, as MSJ suggests.  (Visions of 
downgrade attacks are swimming through my head.)

> 4) What should the actual status be of the new combinations?

Mandatory.  We know that doesn't mean they'll actually be implemented, 
but there's little point in doing something else.  (If we don't think 
we need it, why specify it?)

-- Sam

---

From: Michael StJohns <[email-masked]>
Date: Thu, 01 Nov 2007 19:42:53 -0400

At 18:03 11/1/2007, Sam Weiler wrote:
>In the interest of keeping the complexity to build new resolvers down somewhat, I think we should limit ourselves to only what we think we need.  At any time, I would expect that to be no more than "one hash algorithm we believe is strong enough" and "one or two more, in case we're wrong".  I haven't formed an opinion about exactly which ones we need right now, but if we're defining more than two, we're going down the wrong path.  Do we need something stronger than SHA1?  Probably. Do we need the whole SHA2 suite?  No.  In the absence of a clear sense of what to add beyond SHA256, let's stop at SHA256.

We've specified RSA as a valid key type for digital signatures.  RFC3110 specifies a possible range of strengths for RSA in DNSSEC signatures from 512 to 4096 bits.  NIST (and other cryptographers) have made some strong suggestions about what hashes should match up with which signature lengths - see the tables (2, 3 and 4) in the NIST 800-57 publication.    That table suggests the appropriate match for RSA 2048 bit signatures is SHA224, and for 4096 - SHA384 or greater (SHA256 provides about 128 bits of strength, SHA384 provides 192 bits - RSA 4096 is somewhere between 128 and 192 bits of strength).

Its not about adding SHA256 - its about adding hashes appropriate to cover the range of strengths of the signature methods that have already been approved.

>I think we should NOT split the field, and I think it's actively dangerous to split the registries, as MSJ suggests.  (Visions of downgrade attacks are swimming through my head.)

I'm OK with not splitting the field, but your vision must be from mushrooms.

So what you're saying is the CMS guys got it wrong? I find that hard to believe.

Take a look at a digital certificate for example.  The public key has an OID that identifies it as RSA, DSA or EC (and may provide some additional parameters such as the EC curve).   The SIGNATURE has an oid that identifies it as SHA1withRSA for example.

How the heck would doing this trigger this boogey man of a "downgrade attack"?

Details please - and no visions.

>Mandatory.  We know that doesn't mean they'll actually be implemented, but there's little point in doing something else.  (If we don't think we need it, why specify it?)
>
>-- Sam
>
>
>--

---

From: [email-masked]
Date: Thu, 1 Nov 2007 21:53:16 -0800

> of what to add beyond SHA256, let's stop at SHA256.

FWIW, I completely agree with Sam's rationale. To satisfy Mike's point 
below, we could, instead of SHA256, settle on SHA512. As long as we don't 
need to implement the whole suite. If SHA512 is available, why settle for 
less. 

> We've specified RSA as a valid key type for digital signatures. 
> RFC3110 specifies a possible range of strengths for RSA in DNSSEC 
> signatures from 512 to 4096 bits.  NIST (and other cryptographers) 
> have made some strong suggestions about what hashes should match up 
> with which signature lengths - see the tables (2, 3 and 4) in the NIST
> 800-57 publication.    That table suggests the appropriate match for 
> RSA 2048 bit signatures is SHA224, and for 4096 - SHA384 or greater 
> (SHA256 provides about 128 bits of strength, SHA384 provides 192 bits 
> - RSA 4096 is somewhere between 128 and 192 bits of strength).
> 
> Its not about adding SHA256 - its about adding hashes appropriate to 
> cover the range of strengths of the signature methods that have 
> already been approved.
> 
> 

I haven't seen that statement.

> Take a look at a digital certificate for example.  The public key has 
> an OID that identifies it as RSA, DSA or EC (and may provide some 
> additional parameters such as the EC curve).   The SIGNATURE has an 
> oid that identifies it as SHA1withRSA for example.
> 

I agree with Sam Weilers' point. I'll give you the details:

1) The digest algorithm needs to be present in the DNSKEY RR. If not, then 
DNSSEC will be susceptible to a downgrade attack. Consider an RRSIG with a 
known signature algorithm (say RSA) with an unknown digest. There is no 
fallback to provable unsecure, since nothing can be proven. The only path 
left is to label it bogus. This will cause a significant disruption of 
service that an upgrade to a stronger hash on the server side will be 
avoided. The concept of provable unsecure (or provable unknown) is not 
trivial, but an essential part of the architecture of DNSSEC.

2) We're now left with signalling the digest algorithm in the DNSKEY 
field. There are two possible ways to do this. One is to leave the 
algorithm field to denote the signing algorithm, i.e. no digest algorithm, 
and signal the digest algorithm in the public key field. We now have an 8 
bits field for the signature algorithm, for which we only have 4 
algorithms (DH,DSA,RSA,ECC), and a somewhat odd digest field within the 
public key field. That doesn't look like a clean design either. The other 
option is to split the 8 bits signature field in two. Whatever ratio we 
choose, we now have significantly less space to expand on. Complexity 
doesn't get easier either, since any combination must be possible, since 
every allocated digest algorithm needs to work with every allocated 
signature algorithm. We would also need a new structure for the DS record.

That leaves us with the current status quo. That is not a bad option. I 
would argue it is fairly optimal use of the signature field space. At 
least it is the lesser of all the alternative evils I mentioned above.

> >Mandatory.  We know that doesn't mean they'll actually be 
> implemented, but there's little point in doing something else.  (If we
> don't think we need it, why specify it?)

Agreed.

Regards,

Roy

---

From: Paul Vixie <[email-masked]>
Date: Fri, 02 Nov 2007 07:24:45 +0000

i saw this...

> > we're wrong".  ...
> ... we could, instead of SHA256, settle on SHA512. As long as we don't 

...which reminded me of this:

Subject: Re: Secure DNS Implementation in BIND
From: John Gilmore <[email-masked]>
To: "Paul Rarey" <[email-masked]>, [email-masked]
Cc: "Donald E. Eastlake 3rd" <[email-masked]>, "Carl Malamud [IMS]" <[email-masked]>, [email-masked]
Date: Wed, 08 Oct 1997 19:25:52 -0700

> What happens at the end of three years?

The RSA patent expires, and you don't need to negotiate with RSA to
build a DNS implementation that uses RSA.  Until then, RSA has
committed to offer perpetual DNSsafe licenses to anyone who wants to
implement DNS Security.  If you base your DNSSEC work on BIND, you are
covered by ISC's license; if you have an independent implementation,
you can get your own license from RSA.

	John

---

From: Michael StJohns <[email-masked]>
Date: Fri, 02 Nov 2007 13:15:19 -0400

>need to implement the whole suite. If SHA512 is available, why settle for 

Except that there's a real continuing cost for doing it this way.  SHA512 *is* more expensive to calculate than SHA256 - not a lot, but some.  That's a cost that carries forward on every signing and every verification.  Implementing the whole suite is a cost that happens once, is not all that much more expensive for 4 algorithms as for one, and is spread over all the systems that run that version of the code.  [NB: SHA224 and 256 have approximately the same costs per hash as do SHA384 and SHA512]

The complexity argument doesn't hold water - it's a lookup table that selects three elements - the hash, the signature mechanism and for some (for all of the RSA signatures) the padding.  Implementation wise, the calling sequence for each element is mostly identical within those elements (e.g. same signature calls, same hash calls, same padding calls).

>I haven't seen that statement.

CMS - Cryptographic Message Syntax - all of the PKIX guys.  Not a statement per se, but a method of doing cryptographic operations.  The key type is distinct from all of the possible signature types it can be used to form.  E.g. an RSA key (OID 1.2.840.113549.1.1.1) used in the SubjectPublicKeyInfo field of a certificate is different than the signature algorithm type SHA1withRSA (OID 1.2.840.113549.1.1.5) used to identify the signature over the certificate.

RFC3280.

>I agree with Sam Weilers' point. I'll give you the details:

Roy - I'm not sure what the following is trying to prove.  As I read it, what you've said is that if the signature algorithm field value in  the RRSIG record is unknown, then you can't validate the RRSIG.  Is that correct?  If so, I agree with you.   If I get a value in this field that means "RSA/MIKESHASHALG256" and no one understands it, the RRSIG can't be validated.  The deployment of ANY new value for the algorithm field of the RRSIG will have this same characteristic for some resolvers that didn't get the word.

>trivial, but an essential part of the architecture of DNSSEC.

And this following statement doesn't follow from the previous.  The mis-named algorithm field signals the key type of the DNSKEY.  Or are you saying that a DNSKEY labeled RSA/MD5 can't be used in a RSA/SHA1 signature?

[Sigh - OK - I went back to the source documents and found the source of my and your problem.  In RFC4035 - section 5.3.1 there's this paragraph which says exactly that:

The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
      match the owner name, algorithm, and key tag for some DNSKEY RR in
      the zone's apex DNSKEY RRset.
]

This wasn't in the original DNSSEC (2535) and shouldn't have included "algorithm" in this version - at least in this manner. It should have read "The DNSKEY RR algorithm field must contain a key type which is compatible with the  RRSIG RR's signature algorithm as indicated in the Algorithm field" or something similar. 

I'm not sure what to say here.  I believe the indicated paragraph is incorrect, but its what's standardized.  OTOH, it only affects resolvers, and could be worked around in resolvers that understand the new signature algorithms at the time they're implemented and that's basically what I've proposed.

If you and Sam are saying that if you don't label the key type with the hash algorithm (current model where sig and key type are the same), then the zone owner can use a weaker hash in the signature than intended and that's a downgrade attack?   I'm saying that the choice of security strengths to use in the zone is the zone operator and if he chooses to use a weak hash with a stronger length key - that's his business.  Especially since we don't specify the matching of hash to key length in the first place.

If anyone were still using MD5, you'd have them have to have duplicate DNSKEY records (except for the alg field) to transition into SHA1 land.  (Or at least ANOTHER DNSKEY of the same or longer length).

Aren't the zones large enough already?  Do you want to do this for SHA1 to SHA224 or SHA256 as well?  I'd rather use the existing keys and just transition to the new signature algorithms.

I'm still not sure where the downgrade attack comment comes from.  Given that its your only security argument so far - could you try to clarify it for me please?

So I'm still puzzled about downgrade attacks, but no longer puzzled about the opposition to splitting the registry.

---

From: Sam Weiler <[email-masked]>
Date: Fri, 2 Nov 2007 16:41:55 -0400 (EDT)

First, I think I see the benefit of your proposal -- allowing the same 
public key (RSA or other) to be used to validate signatures generated 
from any of several hash algorithms without adding a new DNSKEY RR to 
the zone for each hash algorithm and, per the current "mandatory 
algorithm rules", an RRSIG for each algorithm on every RRset in the 
zone.  That may look like a substantial benefit, bit I'm not convinced 
it outweighs the complexity cost of adding another crypto parameter 
field.

> cover the range of strengths of the signature methods that have 

No objection re: SHA256 not being the specific chosen next step, but 
do we really need a RANGE of stengths?  Why can't we just pick one 
hash function at the upper end of the range and call it done?

> So what you're saying is the CMS guys got it wrong? I find that hard to believe.

Not at all.  Context is everything.  We need to look at how the 
certificates are being validated and the consequences of failed 
validation.

> Take a look at a digital certificate for example.  The public key 
> has an OID that identifies it as RSA, DSA or EC (and may provide 
> some additional parameters such as the EC curve).  The SIGNATURE has 
> an oid that identifies it as SHA1withRSA for example.
>

The devil is, indeed, in the details.  In this case, it's in the 
details of validator behavior.  It's very hard to provide details of 
how to break something that hasn't been fully specified.  Tell you 
what: spec out your "split the registry" proposal to include the 
details of validator behavior, especially when faced when 
unknown/unsupported/disabled hash algorithms (in various combinations 
with supported and unsupported public key algorithms), and then I'll 
attempt to show you a downgrade attack.  [Or perhaps Roy's post, which 
appeared after I wrote most of this note, will be sufficient.]

Somewhere along the way, I suspect we'll hit the same brick wall that 
we've been hitting since 2002 or 2003, where we find that we have very 
different visions of acceptable validation results and resolver 
behavior.  (Oops, I'm talking about visions again...)

-- Sam

---

From: Michael StJohns <[email-masked]>
Date: Fri, 02 Nov 2007 18:50:06 -0400

At 16:41 11/2/2007, Sam Weiler wrote:

>The devil is, indeed, in the details.  In this case, it's in the details of validator behavior.  It's very hard to provide details of how to break something that hasn't been fully specified.  Tell you what: spec out your "split the registry" proposal to include the details of validator behavior, especially when faced when unknown/unsupported/disabled hash algorithms (in various combinations with supported and unsupported public key algorithms), and then I'll attempt to show you a downgrade attack.  [Or perhaps Roy's post, which appeared after I wrote most of this note, will be sufficient.]

How about I just ask you to do a downgrade attack using currently defined algorithms?

E.g. RSA/MD5 and RSA/SHA1

Resolver understands RSA/MD5 but not RSA/SHA1.  (Yeah, I know - the latter one is mandatory).

If the DNSKEY is RSA/SHA1, the RRSIG is RSA/SHA1 - resolver can't validate it because it doesn't understand the signature algorithm - it doesn't even need to look at the DNSKEY to figure this out.

If the DNSKEY is RSA/SHA1, the RRSIG is RSA/MD5 - 4035 compliant resolver can't validate it because the DNSKEY and RRSIG algorithm IDs don't agree, even though the resolver actually has all the information it needs to validate.

If the DNSKEY is RSA (new approach), the RRSIG is RSA/MD5 - resolver that understands that the algorithm value in the DNSKEY is actually a key type can validate it. 
So the question is - what's the downgrade attack here? 

To go further, without adding any more hashes, let's say the resolver understands both RSA/MD5 and RSA/SHA1.  If the resolver behavior is programmed to say that for any DNSKEY, we ignore the hash component of the algorithm field - e.g. RSA/MD5 and RSA/SHA1 are equivalent values *in a DNSKEY record only*  - what is the downgrade attack there?  E.g. why wouldn't a resolver that understands *and by policy accepts* both hashes, accept an RRSIG with RSA/SHA1 where the DNSKEY it points to is RSA/MD5?  Or vice versa?

So you've got some homework - there are something like 5 cases above - hopefully at least one of them will lead you to a reasonable description of a "downgrade attack".    To succeed, you need to explain why its bad for a resolver to accept a key marked RSA/SHA1 and not accept a key marked RSA/MD5 to validate a signature marked RSA/SHA1 - especially if the key material is identical - the same public key.

I don't think you can do it.. but I might be wrong.

>Somewhere along the way, I suspect we'll hit the same brick wall that we've been hitting since 2002 or 2003, where we find that we have very different visions of acceptable validation results and resolver behavior.  (Oops, I'm talking about visions again...)

---

From: Michael StJohns <[email-masked]>
Date: Fri, 02 Nov 2007 18:59:40 -0400

At 16:41 11/2/2007, Sam Weiler wrote:
>No objection re: SHA256 not being the specific chosen next step, but do we really need a RANGE of stengths?  Why can't we just pick one hash function at the upper end of the range and call it done?

See my discursion in the note back to Roy.

Basically, there's a cost.  SHA224/SHA256 cost about the same (cpu time) for the same data.  SHA384/SHA512 also cost about the same as each other.  However, SHA224/256 cost less than SHA384/512 over a particular data blob.

There's a reason all of these are specified - they have specific strengths and they're designed to go with specific signature key lengths/strength.    We could specify SHA512 for everything, but then we're imposing a higher cost on everyone (signers and resolvers) than we really need to for any given key length.

The cost to implement is trivial - if done all at once.  

But if you want to go with the single hash approach - SHA512 is the one that covers all of the top end ranges of the allowed key lengths for RSA.

---

From: Sam Weiler <[email-masked]>
Date: Mon, 5 Nov 2007 12:20:53 -0500 (EST)

> How about I just ask you to do a downgrade attack using currently 

I'd rather work from a spec, even a very rough one, but I'm willing to 
work from the examples.  Either way, it's vital to separate validation 
failures into the two main cases we defined in DNSSECbis: Insecure and 
Bogus.  (Feel free to treat Indeterminate and Insecure as the same 
state, for the most part.)

Would you flesh out the examples you gave by separating the validation 
failure states?  From that we might be able to infer enough about the 
validation algorithm you intend.

-- Sam

---

From: Michael StJohns <[email-masked]>
Date: Mon, 05 Nov 2007 12:51:14 -0500

Hmm... the red herring of the meta protocol....

This isn't about DNSSEC validation states, this is about cryptographic validation states of a single RRSET.  While the DNSSEC validation state depends on the cryptographic validation state, they are NOT the same thing and the whole discussion about bogus/validated/unsecure/unknown is a meta-red herring.

Take one RRSet of any type.

Take a DNSKEY of type RSA/MD5

Sign the RRSET with that DNSKEY (the private key of course), but using RSA/SHA1 as the signature algorithm.

Cryptographically, the RRSET can be validated using the DNSKEY key material (e.g. the key material is signature algorithm agnostic), but DNSSEC says this isn't kosher because the algorithm fields aren't an exact match. 4035 says the way to do this is to clone the key into another DNSKEY record and change the DNSKEY algorithm type.

Why would changing the DNSKEY algorithm field from a signature algorithm to a key type and as a consequence allow one DNSKEY to be used in multiple signature algorithms allow a downgrade attack?

What is this downgrade attack?

At 12:20 11/5/2007, Sam Weiler wrote:
>I'd rather work from a spec, even a very rough one, but I'm willing to work from the examples.  Either way, it's vital to separate validation failures into the two main cases we defined in DNSSECbis: Insecure and Bogus.  (Feel free to treat Indeterminate and Insecure as the same state, for the most part.)
>
>Would you flesh out the examples you gave by separating the validation failure states?  From that we might be able to infer enough about the validation algorithm you intend.
>
>-- Sam

---

From: "Blacka, David" <[email-masked]>
Date: Tue, 06 Nov 2007 10:28:48 -0500

Michael StJohns wrote:

> Why would changing the DNSKEY algorithm field from a signature
> algorithm to a key type and as a consequence allow one DNSKEY to be
> used in multiple signature algorithms allow a downgrade attack?

> What is this downgrade attack?

So the particular downgrade attack here is the ability for an attacker
to downgrade a zone from SECURE to INSECURE by replacing RRSIGs.

The executive summary here is that by separating the DNSKEY algorithm
from the RRSIG algorithm, you break the chain of trust.

On the surface, separating the registries creates situations that look
analogous to the use of private algorithms today.  However, there is an
important difference.  Let's go over how a validator follows a chain of
trust across a zone boundary.

1) The validator sees a DS RRset.  It validates that RRset using a key
that it trusts.  So far, this is very standard and normal.

2) If, by looking at this DS RRset the validator determines that it
doesn't recognize any of the DNSKEY algorithms present, it can stop
right there and declare the zone INSECURE.  Still, pretty normal.

3) However, looking at the DNSKEY algorithm in the DS records can be
ambiguous.  The current example of this is when private algorithms are
in use.  However, if we adopt your separate registries proposal, it will
always be true.  If the case is ambiguous, the validator delays the
decision.

4) The zone's DNSKEY RRset is fetched and a DS record is matched to a
DNSKEY.  At this point, the validator trusts the matching DNSKEY.  In
the private algorithm case, at this point the validator can determine
what the algorithm actually is and, if it is unrecognized, declare the
zone INSECURE.  In your case, however, it can't.  It only knows that the
 DNSKEY is "RSA" (e.g.) and not that the zone is signed with a hash the
validator supports.

At this point, in the current standard, the validator knows definitively
(and securely) whether the zone is able to be validated.  In your
proposal, it does not.

Under your proposal, the next step would have to be for the validator to
find the signature by the (now trusted) DNSKEY and check the signature
algorithm.  Unfortunately, if that RRSIG uses an algorithm that the
validator doesn't understand, it can't tell if the RRSIG is valid or
not.  That is, it is unable to determine securely whether or not it
should treat the zone as INSECURE or not.

So, that leads to the downgrade attack.  The attacker simply replaces
the DNSKEY RRset RRSIGs with ones of his own devising that use some
unknown algorithm number, thus causing the zone to be downgraded.

The key to this is that currently, DNSSEC *relies* on the fact that a
validator can tell if it can validate something by simply looking at the
DNSKEY.  If it can't, the the DS -> DNSKEY traversal doesn't work.

-- 
David Blacka                          <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Michael StJohns <[email-masked]>
Date: Tue, 06 Nov 2007 23:23:41 -0500

Hi David - thanks for this note - its detailed enough that I now understand the concerns.  I think the certificate equivalent is that your using the algorithm field of the DNSKEY record sort of like the inner signature algorithm field. 

>that it trusts.  So far, this is very standard and normal.

Right.

>right there and declare the zone INSECURE.  Still, pretty normal.

Right.  See my next comment.  I was suggesting changing the meaning of the field in the DNSKEY record. Although 4034 conflates the DS  algorithm field with the DNSKEY record field, I don't think that's necessarily required.

>always be true.  If the case is ambiguous, the validator delays the

Actually, why can't the DS record continue to use the signature algorithm as the value of the field?

As far is I can tell, you're using the fact of the listing of the set of signature algorithms at the parent (in the DS records) as the indication of the required signature algorithms for the child zone.

> DNSKEY is "RSA" (e.g.) and not that the zone is signed with a hash the

Currently, you declare the zone insecure after checking the parent set of algorithms in the DS records doesn't contain a known signature algorithm - correct?  If the DS does contain a known algorithm, the child zone (and its contents) is bogus if the apex DNSKEY record isn't signed with one of those known algorithms? And this carries forward to all of the records within the zone.

So its not actually the presence of the signature algorithm in the apex DNSKEY RRSET that's the problem, but the listing of the algorithm in the parent DS delegation set?  And currently, that has to match up with the child DNSKEY rrset.

>(and securely) whether the zone is able to be validated.  In your

Maybe - see above.   I think this works going forward.  The DS record lists the signature algorithms - each pointing to a key that can form the algorithm.  Deletion of the RRSIG containing that signature algorithm is prevented by the signed indication at the parent.

It probably can't be retrofitted to fold in the current RSA/MD5, RSA/SHA1 - old resolvers will barf on the DS/DNSKEY mismatch - but certainly can for resolvers that understand the new algorithms.  

>DNSKEY.  If it can't, the the DS -> DNSKEY traversal doesn't work.

Yup.  But not the only way to accomplish this required signature algorithm signalling. 

DNSKEYs tend to be fairly large blobs of data - I'd really like not to have to repeat the blob to support multiple signature types. 

Later, Mike