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