SSHFP observation

[Alan Clegg]

On 1/31/19 6:44 PM, Lee wrote:
> On 1/31/19, Alan Clegg <alan at clegg.com> wrote:
>> On 1/31/19 4:57 PM, Mark Andrews wrote:
>>
>>> Given type 1 is a SHA-1 fingerprint it isn’t legal.  Named just
>>> hasn’t added type to length to the parsing code.
>>>
>>> No real SSHFP will be 1 octet long.
>>
>> While I agree that it's junk, the RFC doesn't give the DNS software the
>> ability to make that decision from my reading.
>>
>> There is nothing in the RFC about validating the correctness of the data:
> 
> I'm not following your logic.  The RFC says a field is the fingerprint
> and the user supplied data can't possibly be a fingerprint.  It seems
> to me there's a requirement to reject the user supplied data since it
> can't possibly be a fingerprint.

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.

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."

To be fair, the RFC does point off to the SSH TLS documentation.  If we
wander off into that realm, we may want to start considering validating
that the hex data is a crypto. valid fingerprint, etc. etc.

That's the way I read it.

In any case, either:
  1)  named should not load the zone
        it's just as bad as an A record with 5 octets
        (this is a bug in named)
or
  2)  dig should provide the correct decoding of the
        data provided to it by named.
        (this is a bug in dig)

I don't care which, but I'm leaning towards #2.

And no, an empty field is NOT allowed due to the same logic as "My
reading" above (answering Mark's question that came in while I was
researching and typing this)

Be well, all.

AlanC