On Tue, Feb 20, 2024 at 8:42 AM Edward Lewis <edward.le...@icann.org> wrote:
> On 2/16/24, 15:05, "DNSOP on behalf of Mark Andrews" < > dnsop-boun...@ietf.org on behalf of ma...@isc.org> wrote: > > Pardon ... perhaps this issue has died down, but I've been off a few days, > and I just saw this... > > >Generating a new key is not hard to do. > > That's not the issue, it's knowing that it would be the wise thing to do > that is the issue. > > >Adding a check against the common key store is not hard to do in a > multi-signer scenario. It can be completely automated. > > I'm not in agreement with that. Some keys are managed with off-net HSM > devices, accessed only during a key ceremony. There may be some cases > where the key set is assembled and signed without access of the 'net. This > is a result of an early design rule in DNSSEC, we had to design around a > system that air-gapped the private keys from the open network. > > This does underscore the importance of coherency in the key set even in a > multi-signer scenario. (There was talk of trying to let each server have > its own key set perspective.) In order to detect key tag collisions, the > managing entity has to be able to see the entire set. > > >We could even use the DNS and UPDATE to do that. Records with tuples of > algorithm, tag and operator. Grab the current RRset. Add it as a > prerequisite with a update for the new tag. > > This approach leaves open a race condition. It's possible that two > signers simultaneously generate keys with colliding key tags and each gets > to add because they don't see each other. My point, while this is > admirable, achieving the perfect solution is out of reach, so let's not > assume we can ever totally avoid key tag collisions. > > My thesis is - key tag collisions are not the driver for validation > resource consumption. In the research paper, collisions do contribute by > scaling the impact up. Through using invalid signature values, resource > consumption can be drained by throwing multiple "good-looking" signatures > along with data set and having many keys. The fact that key tags can > collide only mean that I can cause multiple checks per signature, which may > help hide my malicious tracks. > > And remember, the paper requires that the crypto operations always fail. > I.e., the is no success to be missed by not trying all the combinations of > keys and signatures. A simple timer is all that is needed. > > Key tag collisions are a pain in key management, operators that have > experienced them have shown not to tolerate them for long even if there > were no outages. To me, whatever can be done to easily avoid them would be > good, trying to define an interoperable way (standard) to eliminate them > would prove to be overkill. And...my original point was...don't include > this idea in a future design. > > " don't include this idea in a future design." But if I have a 'standby' DS record, to allow faster rollover if a key is compromised, then there will always be two DS records. And without a key tag or equivalent, resolvers would have to do extra work to check the DS record because they would not know which one was active. Key tags add efficiency, we just need to handle occasional collisions. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
