On 29-Dec-22 18:37, Eric Germann wrote:
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.


S_omehow or another _they are getting the key tag from the incorrect DS  record, because they _encode again the already encoded string_.
This isn't quite what's happening.

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.

The key tag is just a folded checksum (https://datatracker.ietf.org/doc/html/rfc2535#page-46, 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.

So they _decode_ the DS HASH to binary - which will work. Apply the checksum, and you have a "keytag" - or something that looks like one.

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.

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), ...

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.

The problem is politics, not technology.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to