<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2/21/2018 10:25 AM, Paul Hoffman
wrote:<br>
</div>
<blockquote type="cite">
<pre wrap="">Warren's point (which many other people gave a +1 to, and IANA said they intend to implement) is not to prevent two identical keytags in the root zone DNSKEY RRset (Mike) or anywhere in the root zone (Ed), it is to prevent confusion in other places where the key tag is used, such as trust anchor stores. The key tag is used in many places where an operator would enter, or at least check, the trust anchors.</pre>
</blockquote>
<br>
Um any code stupid enough to use the key tag as a solid handle for
the key should be ripped out and stomped on. AFAICT, the key tag
calculation is no better than a CRC in cryptographic strength - and
only 16 bits at that. What should be happening is that entering the
presentation form of the DS as a trust anchor should grab the
referred to DNSKEY, do a calculation and compare the calculated
trust anchor key tag to the entered one. I'd surprised if enough
implementations do that.<br>
<br>
<blockquote type="cite"
cite="mid:77116395-DAFB-42CA-A2D5-7C12AA6A5B92@icann.org">
<blockquote type="cite" style="color: #000000;">
<pre wrap="">So if you're really going down this path, you've probably got a lot more work than just checking against older KSKs.
</pre>
</blockquote>
<pre wrap="">I fully disagree with this, and with Ed's assertions. Checking for a matching key tag in the current and previous KSK set is sufficient to reduce ambiguity for manual use of key tags, which is what Warren's suggestion was about.</pre>
</blockquote>
So what you're saying is that you're going to conditionally repeat
an operation that has a ritual associated with it (and indeed
modify the ritual so this happens) until you get non-matching key
tags for the sole purpose of someone later on looking at the key and
saying "not a match". A complex ritual with specific requirements
and a large cost in human time... OK.<br>
<br>
Key tags exist on DS records and RRSig records. In the DS records,
the hash of the key is a better handle to differentiate possibly
matching keys. In the RRSig records - you're kind of stuck in that
you possibly don't know who of multiple possibilities signed the
record until after you've checked all of the tag matching signing
keys.<br>
<br>
To his basic point of RFC8145 and KSK sentinel - if you're using the
Key Tag as a handle then all of the "you must accept ambiguity"
stuff from Appendix B of RFC4034 applies. Perhaps using something
other than the key tag (e.g. hash of the public key - the first and
last 4 bytes of the public value of the key... ) might have been
smarter. Say something with at least 32 and preferably 64 bits of
uniqueness rather than the 16 bits of the key tag.<br>
<br>
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.<br>
<br>
(And by the way - does any of the 8145 or KSK sentinel
implementations correctly match a revoked key with its unrevoked
brother?)<br>
<br>
Later, Mike<br>
<br>
</body>
</html>