[Dnssec-deployment] cases - was Re: Barbie sez: "Algorithm rollovers are HARD!"
Ed.Lewis at neustar.biz
Tue Aug 17 10:17:29 EDT 2010
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
>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.
The problem is that the specification is not conveying the right
message. (I know because I was heavily into the crafting of the
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
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
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.
NeuStar You can leave a voice message at +1-571-434-5468
Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
More information about the Dnssec-deployment