[Dnssec-deployment] cases - was Re: Barbie sez: "Algorithm rollovers are HARD!"

[Edward Lewis]

At 6:43 -0700 8/17/10, Michael Sinatra wrote:

>I didn't intend to imply that it was a protocol issue, only an unintended
>difficulty caused by the protocol specification's desire to avoid
>downgrade attacks.  But it is useful to think about if/how the protocol
>might be more accommodating.

It's my job to make sure the protocol is right... ;) so if it sounds 
like it might be a protocol problem I look at it closely.

(Skipped Q2 becuase I'm addressing it as part of the reply to Finch's 
comment below.)

>Does the cache have any way of knowing that this case [III] is different that
>case VII?  It simply knows that it has a signature that doesn't match
>the algorithm of the key in the apex rrset.

No, it would be temping to use the signature inception and expiration 
dates, but they could also be overlapping.  III and VII do result in 
the same thing.

>Since you also have to avoid cases II and VIII, which will produce validation
>failures (at least with unbound--some versions of BIND will validate), the
>administrator of an authoritative zone must carefully negotiate the path along
>the following of your cases (while allowing time in between each stage for TTL
>expiration): I -> IV -> V -> VI -> IX.  This is different from an ordinary KSK
>rollover, where the admin doesn't really have to worry about the same issues
>as long as s/he correctly manages his/her parent's DS records.

The protocol shouldn't be so rigid.  States II and VIII aren't 
supposed to be problem states.  I'll address that below.

At 14:35 +0100 8/17/10, Tony Finch wrote:
>On Tue, 17 Aug 2010, Edward Lewis wrote:
>>
>>  The cache has:-->    old-alg-only        both-alg-keys         new-alg-only
>>  The cache gets-v
>>  Old sig only              I                   II                  III
>>  Both sigs                 IV                   V                   VI
>>  New sig only             VII                 VIII                  IX
>>
>>  Case I, II, IV, V, VI, VIII, IX are no problem, right?
>
>Cases II and VIII must cause a validation failure since every RRset must
>be signed by every algorithm.

I see.

The problem is that the specification is not conveying the right 
message.  (I know because I was heavily into the crafting of the 
requirement.)

The motivation for the specification statement is to avoid a 
downgrade vulnerability.  If it were optional to generate a 
signature, then it would be easy to fool a validator into dropping 
its checking procedure.  By requiring a signer to generate a 
signature for each algorithm this meant that a stripped signature 
wouldn't lead a validator to ever assume that the data was 
intentionally unsigned.  That is, a validator should assume a record, 
in a secure subtree, is signed unless proven otherwise.

The reason one of "every algorithm" is mentioned is to cover the case 
where some population of validators did not implement a particular 
cryptographic algorithm. If a validator saw the DS set and validated 
it, the validator could then flip through the DS records and 
determine if there was any key whose algorithm was understood.  It's 
possible that a zone has a DS record but a validator would proceed as 
if the zone was not signed because the signatures would be 
unparseable.

The problem with the specification language is that I didn't give a 
thought to a mismatch of an old key set and a new data set (or vice 
versa).  This can only happen in a cache.  The requirement was 
written in the context of the signer, which always has access to the 
current key and data sets.

What should be happening at the validator is that if it can validate 
the set with the available signature and an key on hand, that is 
sufficient.  A validator should not worry about what might be other 
stripped signatures.  A validator should not consider case II and 
VIII as failed states - it is not INTTENDED that a validator should 
check for other algorithms.

I've said before that DNSSEC has to be loose in it's judgement.  The 
DNS is loose.  If DNSSEC gets too pendantic, then we crack the DNS. 
Validators have to establish "some way" of validating data and if any 
one path works, cling to it.  DNSSEC is supposed to make sure every 
nook-and-crany is clean, just that the data is verifiable.

I've also said that DNSSEC is about the protection of the cache, not 
the authority, the authority is merely offering up ancillary 
attestations that a validator can use to establish confidence in the 
data.  In this case, the signer is told to generate all the 
signatures because you don't know what the validator will pick to 
use, the validator knows that there should be at least on signature 
it can use if the set is signed.

DNSSEC is supposed to be liberal in accepting data that has a shred 
of a trust chain.  DNSSEC isn't there to deny based on 
"technicalities."

Cases II and VIII, the cases where a cache has many algorithm keys 
for a zone yet sees just one useful signature should result in a 
thumbs up in validation.

Implementors may feel that's too loose, but it was what was meant in 
the design of the protocol extensions.  To clean up the 
specification, it should be emphasized that although the signer is 
supposed to supply one of every signature, the validator only needs 
one working signature to okay the data.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.