Re: [dnsext] Clarifying the mandatory algorithm rules

[Edward Lewis <[e-mail]>]

Apologies for not thoroughly reading the thread (volume is 
overwhelming), but I wanted to send this which I sent privately to 
Ondrej.  The reason is that I don't think anyone has properly stated 
the "use case" that prompted the questioned text.  (E.g., it isn't 
about algorithm "strength".)

Using a proof-by-contradiction approach, let's assume a signer *does 
not* have to have a signature by every algorithm at each and every 
set.

Let's say a signer has an alg 5 and alg 8 key in DS/DNSKEY and 
decides to signs all sets owned by names from a-m with alg 5 and all 
others with alg 8.  This decision is not expressible in the protocol 
(meaning the signer can't signal this to the verifier).

Let's say a verifier has implemented alg 5 but not alg 8.  When it 
asks for a set beginning with "a" it is supposed to arrive with a 
signature of alg 5.  The verifier should be able to validate the set. 
We know that only because we have "above vision" - knowing the intent 
of the sender.

If the verifier gets the set desired but there is an alg 8 signature 
there and no alg 5 signature, the verifier has no choice but to 
accept the data, even if the data has been forged.  Without the 
knowledge that the signer must have alg 5 and alg 8 signatures at the 
set, the verifier would be correct to conclude that this set was 
signed only by 8 and not by 5, thus out of bounds for the verifier.

The problem is, we know that the set was signed only by alg 5.  What 
happened is an interloper stripped off the legitimate alg 5 signature 
and inserted a completely bogus alg 8 signature - perhaps merely by 
changing the 5 to an 8 - and changing the data (maybe).  Recall that 
the verifier has not implemented alg 8 and hence cannot determine 
that the signature is bogus.

So, because the verifier is in an undecidable position - it can't 
distinguish between properly signed by alg 8 or improperly stripped 
of an alg 5, we have to require the signer include both.  The intent 
of this rule is to allow the verifier to have a "right to expect" an 
algorithm it can handle (given that the algorithm is in the DS and 
DNSKEY sets).  The intent was never to "look for trouble" in the 
sense that Unbound does.

- In summary, what we were concerned about was supporting old 
resolvers that didn't know about some algorithms, not a choice of 
algorithm situation.  And we were trying to make sure the protocol 
had a sufficient specification because we couldn't convey policy 
in-band.

- What the text missed was we didn't properly account for caching 
behavior and transition states.  (The latter a genetic problem in 
IETF solutions.)

- Oh, and yes, we probably could scope the requirement to the set of 
algorithms with keys that have an SEP bit set.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?