RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)
Timothe Litt
litt at acm.org
Fri Dec 30 00:31:27 UTC 2022
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221229/90e00282/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221229/90e00282/attachment-0001.sig>
More information about the bind-users
mailing list