From michael@malcolm.berkeley.edu  Wed Aug 20 19:35:49 2008
Return-Path: <michael@malcolm.berkeley.edu>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7B7EC106566B
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 20 Aug 2008 19:35:49 +0000 (UTC)
	(envelope-from michael@malcolm.berkeley.edu)
Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239])
	by mx1.freebsd.org (Postfix) with ESMTP id 623128FC21
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 20 Aug 2008 19:35:49 +0000 (UTC)
	(envelope-from michael@malcolm.berkeley.edu)
Received: from malcolm.berkeley.edu (localhost [127.0.0.1])
	by malcolm.berkeley.edu (8.14.2/8.13.8m1) with ESMTP id m7KJZn0l037534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 20 Aug 2008 12:35:49 -0700 (PDT)
	(envelope-from michael@malcolm.berkeley.edu)
Received: (from michael@localhost)
	by malcolm.berkeley.edu (8.14.2/8.13.3/Submit) id m7KJZnht037533;
	Wed, 20 Aug 2008 12:35:49 -0700 (PDT)
	(envelope-from michael)
Message-Id: <200808201935.m7KJZnht037533@malcolm.berkeley.edu>
Date: Wed, 20 Aug 2008 12:35:49 -0700 (PDT)
From: Michael Sinatra <michael@malcolm.berkeley.edu>
Reply-To: Michael Sinatra <michael@malcolm.berkeley.edu>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: DNSSEC cryptographic validation doesn't work on amd64 (openssl problem)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         126693
>Category:       amd64
>Synopsis:       openssl(1): DNSSEC cryptographic validation doesn't work on amd64
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-amd64
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 20 19:40:01 UTC 2008
>Closed-Date:    Tue Aug 26 14:37:53 UTC 2008
>Last-Modified:  Tue Aug 26 14:37:53 UTC 2008
>Originator:     Michael Sinatra <michael-pr@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@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:

From: Michael Sinatra <michael@rancid.berkeley.edu>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-amd64@FreeBSD.org
Cc:  
Subject: Re: amd64/126693: DNSSEC cryptographic validation doesn't work on
 amd64	(openssl problem)
Date: Mon, 25 Aug 2008 10:29:03 -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@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@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:
 

From: Michael Sinatra <michael@rancid.berkeley.edu>
To: bug-followup@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@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@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:
 
 
State-Changed-From-To: open->closed 
State-Changed-By: arved 
State-Changed-When: Tue Aug 26 14:37:40 UTC 2008 
State-Changed-Why:  
Submitter reports it was a local problem 

http://www.freebsd.org/cgi/query-pr.cgi?pr=126693 
>Unformatted:
