[dns-operations] DNSSEC and FIPS-140

[Viktor Dukhovni]

On Sat, Dec 01, 2018 at 03:23:10PM +0000, James Stevens wrote:

> We're running a PowerDNS Master on RHEL 7 installed with FIPS compliance,

Presumably OpenSSL 1.0.2 with the OpenSSL FIPS module version 2.0.9.
There is not yet a FIPS module for the new OpenSSL 1.1.0 and 1.1.1
releases, design discussions for that are under way now, and if all
goes well a FIPS validated OpenSSL 3.0 will be available (for some
validated platforms) some time in 2019.

In DNSSEC, MD5 is only "needed" for the long deprecated algorithm 1
(RSAMD5):

  https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1

Among the ~9 million domains covered in my DANE/DNSSEC survey, only
31 list RSAMD5 (algorithm 1) in their DS records.  Of these 11 also
list some of the usual algorithms (5, 7, 8 or 13), and validate
with one of those.  None publish RSAMD5 keys.

Two domains are up and running, but always fail validation (no DNSKEY
RRset returned):

    http://dnsviz.net/d/0jl.com/XALVSA/dnssec/
    http://dnsviz.net/d/sdi-gh.com/XALXmQ/dnssec/

the remaining 18 are simply out of service, with or without validation.

Bottom line, RSAMD5 is not only deprecated, but is also at this
point *never* used.  Server and resolver implementations can and
should remove the code point from the library, and treat RSAMD5 as
"unknown", with any domains that publish only RSAMD5 treated as
unsigned.

> ... but this query will crash PowerDNS ...
> 
> $ dig +dnssec @127.0.0.1 example.com soa
> 
> By "crash" I mean PowerDNS core-dumps - interestingly with signal 6, 
> SIGABRT - so sounds like some kind of assertion has failed - like you 
> said, looks like this needs to be taken up elsewhere.

A lot depends on how PowerDNS "uses" MD5, which in DNSSEC is only
If it directly uses MD5_Init, MD5_Update(), MD5_Final() or EVP_md5()
(you should be able to see the symbols used via "nm" or "objdump
-T") and the OpenSSL library is built with MD5 disabled, late
binding of dynamic symbols might leed to a failure when these
functions are first accessed.

The recommended way to access EVP digest algorithms is via:

	EVP_get_digestbyname()
	EVP_get_digestbyobj()

which won't crash when an expected algorithm is not present in the
library, but will return NULL handles, that the application can
check for, and continue without the algorithm in question, treating
it as unsupported.  PowerDNS should avoid direct access to specific
agorithms, and should use the algorithm-independent lookup functions.

-- 
	Viktor.