<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 29-Dec-22 18:37, Eric Germann wrote:<br>
</div>
<blockquote type="cite"
cite="mid:sig.6362ba69ad.6650A96A-6B6D-4292-9DC2-BB3B93E02B8D@semperen.com">
<div>The really annoying part is it isn’t obvious that they want
the public key and not the result of dnssec-dsfromkey; they do
it themselves. The annoying part is they throw an error if the
key isn’t valid Base64 (think spaces or newlines), but gladly
accept the DS output from dnssec-dsfromkey. Somehow or another
they are getting the key tag from the incorrect DS record,
because they encode again the already encoded string.</div>
<div><br>
</div>
</blockquote>
<p><br>
</p>
<p>
<blockquote type="cite">S<u>omehow or another </u>they are
getting the key tag from the incorrect DS record, because they
<u>encode again the already encoded string</u>.</blockquote>
This isn't quite what's happening.<br>
</p>
<p>There is no mystery here. The DS hash data is expressed in hex.
All hex characters are valid base64. the DS hash is 64 characters
long, which is a multiple of 4. So no padding is required. Thus,
it's a valid string and can be decoded into 48 bytes.<br>
</p>
<p>The key tag is just a folded checksum (<a moz-do-not-send="true"
href="https://datatracker.ietf.org/doc/html/rfc2535#page-46"
class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/rfc2535#page-46</a>,
which doesn't care what data it's working on. It's supposed to be
on the KEY RR, but there's not much you can say about a key unless
you know the type that determines its structure. So its perfectly
reasonable to compute it blindly over what data is presented.<br>
</p>
<p>So they <u>decode</u> the DS HASH to binary - which will work.
Apply the checksum, and you have a "keytag" - or something that
looks like one.</p>
<p>By chance, DS has 4 RDATA fields: tag, alg, type, digest. And
DNSKEY has 4: flags, proto, alg, key. In both cases, the first
tree are decimal numbers. So, they look the same to a decoder.<br>
</p>
<p>That said, I agree that it should be obvious what they want.
E.g. put a sample record above the input box. And say "KEY". For
extra credit, check that the length matches the key algorithm;
make sure that an RSA key is odd (if not prime), ...<br>
</p>
<p>What I've seen from others is that DNSSEC is not viewed as
important enough to merit a careful human factors design for the
interfaces. It's more "what's the minimum we can do to quiet
those few people who insist on it?". So they don't label the
fields in their forms, don't provide meaningful help, don't
advertise the capability. And, surprise, only the truly motivated
people use it. And those customers are so grateful to have
anything that no complaints are received. Which discourages
adoption, keeps the user base small, validates the "don't do much"
strategy, and - catch-22, DNSSEC doesn't expand beyond the
hardcore techies.</p>
<p>The problem is politics, not technology.<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<p></p>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>