SSHFP observation
Mark Andrews
marka at isc.org
Fri Feb 1 00:19:41 UTC 2019
> On 1 Feb 2019, at 11:10 am, Alan Clegg <alan at clegg.com> wrote:
>
> 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.
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.
> 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.
> 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
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list