SSHFP observation

[Alan Clegg]

On 1/31/19 7:19 PM, Mark Andrews wrote:

>> Question: How does named (actually 'dig') know that any given data (in
>> this case "AA") can't be a fingerprint?
>> Difficulty: You are only allowed to use the information provided in RFC
>> 4255 and errata in your answer.
> 
> Mathematics.  I’ll presume I can use all of the RFC some of which state
> minimum sizes for cryptographic hashes.  Developers are expected to use
> all their knowledge.

Developers are supposed to follow the RFC.  For "future proofing", I
can't see adding a constraint that isn't in the RFC.

> There is no minimum size on that field though clearly 8 bits
> is insane. Is a empty field allowed?

I'm not going to question anyone's sanity.  We do DNS for a living.  How
sane is that?  Hmmmmm?  Yeah, thought so.

>> My reading: The RFC doesn't specify what a fingerprint is other than "an
>> opaque octet string [..] which is placed as-is in the RDATA fingerprint
>> field.”
> 
> It also specifies that 1 is SHA-1 and there is a followup RFC that specifies
> 2 is SHA256.  In this case the record is clearly wrong as it is too short
> to be SHA1.

That means that we have a BUNCH of "still to be allocated" algorithms.
I'm not smart enough to say exactly what they are going to need to
encode in that "fingerprint" field other than something encoded in hex.
 One byte?  More?  Sure!

The RFC doesn't specify a minimum,  named doesn't enforce a two-byte
minimum - what are we arguing about again?

Oh yeah... dig doesn't like one byte.

So... WHY are we arguing about this?