RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Timothe Litt]

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>