SSHFP observation

[Mark Andrews]

> On 1 Feb 2019, at 10:44 am, Lee <ler762 at gmail.com> 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.

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

For digest types 1 and 2 we know what the field size is.  For the rest
it is a unknown.  SSH needs to check the rdata size.  Name servers not
so much.  They can just push the bits.  Some responsibility needs to
fall on the operator.

Named allowed you to load garbage in that field.  Meh.

> Regards,
> Lee
> 
>> 
>> --
>>   The RDATA of the presentation format of the SSHFP resource record
>>   consists of two numbers (algorithm and fingerprint type) followed by
>>   the fingerprint itself, presented in hex, e.g.:
>> 
>>       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
>> --
>> 
>> AlanC

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org