On 2/21/2018 2:40 PM, Wessels, Duane wrote:
On Feb 21, 2018, at 2:28 PM, Geoff Huston <gih@apnic.net> wrote:
So my base point is - don't try to fix the wrong problem. Key tags are what they are and will remain as such. With 16 bits, collisions are inevitable at some point and may actually occur *after* the keys are generated (- revoked keys). Fix 8145 and KSK sentinel instead.
(And by the way - does any of the 8145 or KSK sentinel implementations correctly match a revoked key with its unrevoked brother?)
I don't understand this question Mike - particularly “unrevoked brother” - could you describe in a little more detail what you are referring to here? Setting the revoke bit on a key changes its keytag. Mike seems to be suggesting that maybe a query/signal for an unrevoked key should also match the revoked key.
I'd say it should not in these cases. Revoked keys should not be part of the trust anchor set and should not be matched.
DW
Close to what I was thinking - but its more whether you can identify a revoked key that *was* a trust anchor where you're trying to figure out the state of the trust anchors for a particular resolver. 5011 says to hang on to revoked keys for a bit (remove hold down time) in the trust anchor store and depending on whether or not implementers followed that guidance you might be getting weird results. (Note - I have not read either of the two documents deeply so this is more of a "have you considered" rather than a pointer to a bad situation.) You may also want to consider the the situation of Root DNSKEY RRset = { Knew, Revoked(Kold)} and where KeyTag(Knew) == KeyTag (Revoked(Kold)). During the time that you're recording the revocation of KOld, there will be two RRSigs over the DNSKEY RRSet both with the same key tag - one by Kold and one by Knew I don't know what that does for the various schemes, but is a condition that's possible. Reviewing the key tag calculation - this is a basically the sum of the key bytes expressed as big endian shorts with the carry bits added back in and masked to 16 bits. I would have to run some simulations, but I would expect the values to have a bias of some amount - so not maybe a 1 in 64K chance of collision. *bleah* Mike