amd64/126693: DNSSEC cryptographic validation doesn't work on amd64 (openssl problem)

[Michael Sinatra]

The following reply was made to PR amd64/126693; it has been noted by GNATS.

From: Michael Sinatra <michael at rancid.berkeley.edu>
To: bug-followup at freebsd.org
Cc:  
Subject: Re: amd64/126693: DNSSEC cryptographic validation doesn't work on
 amd64	(openssl problem)
Date: Mon, 25 Aug 2008 10:29:54 -0700

 I determined this problem to be a rather complex interaction between
 DNSSEC, pf configurations, and the different IP subnets that the hosts
 were on.  After some testing, I can verify that DNSSEC validation works
 on 6.3-RELEASE, 8-CURRENT, and 7-STABLE, all on the amd64 platform.
 
 I'll request that this PR be closed.  Sorry for the noise.
 
 michael
 
 On 08/20/08 12:35, Michael Sinatra wrote:
 >> Number:         126693
 >> Category:       amd64
 >> Synopsis:       DNSSEC cryptographic validation doesn't work on amd64 (openssl problem)
 >> Confidential:   no
 >> Severity:       non-critical
 >> Priority:       medium
 >> Responsible:    freebsd-amd64
 >> State:          open
 >> Quarter:        
 >> Keywords:       
 >> Date-Required:
 >> Class:          sw-bug
 >> Submitter-Id:   current-users
 >> Arrival-Date:   Wed Aug 20 19:40:01 UTC 2008
 >> Closed-Date:
 >> Last-Modified:
 >> Originator:     Michael Sinatra <michael-pr at rancid.berkeley.edu>
 >> Release:        FreeBSD 7.0-STABLE amd64
 >> Organization:
 > University of California, Berkeley
 >> Environment:
 > System: FreeBSD drl9.berkeley.edu 7.0-STABLE FreeBSD 7.0-STABLE #3: Thu Aug 14 09:44:49 PDT 2008     michael at drl9.berkeley.edu:/usr/obj/usr/src/sys/DRL  amd64
 >> Description:
 > 
 > DNSSEC validation fails on FreeBSD/amd64, regardless of the DNS
 > server (caching resolver software being used).  Attempting to use
 > both BIND (9.4.2-P2 and 9.5.0-P2) and unbound (1.0.2) yields errors
 > when DNSSEC validation is attempted.  These errors do not occur
 > with the very same configuration on i386.  The errors that occur
 > indicate that the digital signatures are bad; when the same
 > trust-anchors and queries are made on i386, they properly validate.
 > 
 > This appears to be an issue with OpenSSL.  Currently, all DNSSEC
 > signing keys that I have found are of type RSASHA1; I have therefore
 > not been able to test it with DSA keys.
 > 
 > This issue does not occur on Gentoo Linux--both i386 and x86_64 can
 > run a validating connfiguration of BIND..
 > 
 > CSUP and rebuild of the system in question was done on the same day
 > that the kernel was built.  Other systems--all rebuilt in July or
 > August--have also been tested with the same result.
 > 
 >> How-To-Repeat:
 > 
 > 1. Install stock FreeBSD/amd64 system.  csup-and-rebuild to a recent
 > version.
 > 
 > 2. Install unbound from ports.  Configure to be a caching resolver.
 > 
 > 3. Add the following line to /usr/local/etc/unbound/unbound.conf:
 > 
 >         trust-anchor: "se. DNSKEY 257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc="
 > 
 > 4. dig +dnssec se @localhost (or whatever interface unbound is listening on)
 > 
 > 5. On i386, you get a validated response (with the ad bit set). On
 > amd64, you get a SERVFAIL.
 > 
 > ALTERNATE STEPS 2-5 with BIND:
 > 
 > 2. Install either bind94 or bind95 from ports.  Make any necessary
 > mods to the config in /etc/namedb/named.conf bundled with FreeBSD
 > to get a basic caching resolver working.
 > 
 > 3a. add the following lines to /etc/namedb/named.conf in the 'options'
 > section:
 > 
 >   dnssec-enable yes;
 >   dnssec-validation yes;
 >   dnssec-lookaside . trust-anchor dlv.isc.org;
 > 
 > 3b. Add the following lines to the global section of /etc/namedb/named.conf:
 > 
 > trusted-keys {
 >     dlv.isc.org. 257 3 5 "BEAAAAPp1USu3BecNerrrd78zxJIslqFaJ9csRkxd9LCMzvk9Z0wFzoF kWAHMmMhWFpSLjPLX8UL6zDg85XE55hzqJKoKJndRqtncUwHkjh6zERN uymtKZSCZvkg5mG6Q9YORkcfkQD2GIRxGwx9BW7y3ZhyEf7ht/jEh01N ibG/uAhj4qkzBM6mgAhSGuaKdDdo40vMrwdv0CHJ74JYnYqU+vsTxEIw c/u+5VdA0+ZOA1+X3yk1qscxHC24ewPoiASE7XlzFqIyuKDlOcFySchT Ho/UhNyDra2uAYUH1onUa7ybtdtQclmYVavMplcay4aofVtjU9NqhCtv f/dbAtaWguDB";
 > };
 > 
 > 4. dig +dnssec br @localhost (br is in the ISC DLV registry)
 > 
 > 5. On i386, you get a validated response (with the ad bit set). On
 > amd64, the query simply times out.  If you change the trusted-key
 > to something obviously bogus, the exact behavior on amd64 is
 > replicated.  The debug logs show the same--the key appears to be
 > bad.
 > 
 > It appears that cryptographic processing for RSASHA1 on amd64 just
 > isn't working quite right, which is why I suspect something in
 > OpenSSL.
 > 
 >> Fix:
 > 
 > The following things HAVE NOT WORKED:
 > 
 > 0. Using the OpenSSL installed in the base system.
 > 
 > 1. Using latest ports version of OpenSSL and linking BIND against it.
 > 
 > 2. Compiling ports version of OpenSSL with -O instead of -O3 and
 > linking BIND against it.
 > 
 > 3. Using a different version of gcc (3.3.6 and 4.4.0 both tried)
 > to compile OpenSSL from ports & linking BIND to that.
 > 
 > 4. Compiling static ports OpenSSL libraries and statically linking
 > BIND against it.
 > 
 > 5. Compiling ports OpenSSL with the 'no-asm' option and linking
 > BIND to it.
 > 
 > I'll happily try other workarounds/suggestions.
 >> Release-Note:
 >> Audit-Trail:
 >> Unformatted: