> On 1 Feb 2019, at 11:10 am, Alan Clegg <a...@clegg.com> wrote: > > On 1/31/19 6:44 PM, Lee wrote: >> On 1/31/19, Alan Clegg <a...@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@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: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
