[dnsop] BIND and OpenSSL's RSA signature forging issue
I've just noticed that BIND is vulnerable to: http://www.openssl.org/news/secadv_20060905.txt Executive summary: RRSIGs can be forged if your RSA key has exponent 3, which is BIND's default. Note that the issue is in the resolver, not the server. Fix: Upgrade OpenSSL. Issue: Since I've been told often that most of the world won't upgrade resolvers, presumably most of the world will be vulnerable to this problem for a long time. Solution: Don't use exponent 3 anymore. This can, of course, be done server-side, where the responsible citizens live, allegedly. Side benefit: You all get to test emergency key roll! Start your motors, gentlemen! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: [dnssec-deployment] BIND and OpenSSL's RSA signature forging issue
Ben Laurie wrote: I've just noticed that BIND is vulnerable to: http://www.openssl.org/news/secadv_20060905.txt Executive summary: RRSIGs can be forged if your RSA key has exponent 3, which is BIND's default. Note that the issue is in the resolver, not the server. See a more comprehensive report at Hal Finney, Bleichenbacher's RSA signature forgery based on implementation error Wed, 30 Aug 2006 http://www.mail-archive.com/cryptography@metzdowd.com/msg06537.html based on implementation error is somehow relevant to understand exactly where the vulnerability lies. I mean somehow relevant because the specific implementation error (a missing data validation check, where the check is useful *only* for preventing the Bleichenbacher's RSA signature forgery while the forgery was previously unknown) is very likely to be done by even dedicated implementation developers, and remain undetected in the SW testing phase because of its innocuous-ness. Fix: Upgrade OpenSSL. Or use the proper command-line argument in the BIND-specific dnssec-keygen utility? Or fix the BIND-specific dnssec-keygen utility to use the other allowed value (i.e 65537) as the default? Issue: Since I've been told often that most of the world won't upgrade resolvers, presumably most of the world will be vulnerable to this problem for a long time. Solution: Don't use exponent 3 anymore. This can, of course, be done server-side, where the responsible citizens live, allegedly. Side benefit: You all get to test emergency key roll! Start your motors, gentlemen! Responsible citizens consult their family cryptographer before selecting an RSA public key exponent, and they stay away from public exponent=3 for number-theoretic reasons known only to the family cryptographers (of which the Bleichenbacher's RSA signature forgery is an acutely practical consequence)! Cheers, Cheers, Ben. - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Re: [dnssec-deployment] Ripe and SE keyroll
Roy Arends wrote: fyi I noticed that SE uses e=65537 for their KSK and e=3 for their ZSKs. This means that the keyroll (all zsk's need to be e3) should go smoothly and no emergency trust anchor rollover is needed. This is not the case for RIPE (194.in-addr.arpa). RIPE uses e=3 for both ZSK and KSK. Hence an emergency trust anchor roll is needed. Perhaps you may check if BIND DNSSEC signature verification, which is different from SSL X.509 security certificate signature verification, actually does have the implementation flaw?? The protocol formats are different, and the X.509 format is more fertile ground for implementation error, because the message payload length is self-encoded in ASN.1 encoding, and duplicated in the message header length. In RFC3035 section 5.3.2 and RFC3110, it is possible that either 1) BIND does not rely on OpenSSL for length checking concurrent with RSA validation, and/or 2) BIND software can in no circumstances pass erroneous length indications to OpenSSL (after all, DNSSEC spec tells implementers to *reconstruct* input to the RSA signature verification routine). If it (BIND + deployed SEP KSKs) isn't broken, don't fix it as an emergency response to a false alarm. On the other hand, we deprecate public exponent 3 in *any* operational use of RSA cryptosystem, so we spare ourselves a few emergency responses in a 10-year horizon. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
[dnsop] Ripe and SE keyroll
fyi I noticed that SE uses e=65537 for their KSK and e=3 for their ZSKs. This means that the keyroll (all zsk's need to be e3) should go smoothly and no emergency trust anchor rollover is needed. This is not the case for RIPE (194.in-addr.arpa). RIPE uses e=3 for both ZSK and KSK. Hence an emergency trust anchor roll is needed. Regards, Roy . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Re: [dnsop] Ripe and SE keyroll
[EMAIL PROTECTED] (Roy Arends) writes: This is not the case for RIPE (194.in-addr.arpa). RIPE uses e=3 for both ZSK and KSK. Hence an emergency trust anchor roll is needed. i'd argue that if 194.in-addr.arpa is not registered a DLV registry and if in-addr.arpa is not itself signed, then the community of beneficiaries of 194's signedness is so small that this cannot be called an emergency. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email [EMAIL PROTECTED] -- Paul Vixie . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Re: [dnsop] Ripe and SE keyroll
On Sep 8, 2006, at 7:32 PM, Paul Vixie wrote: [EMAIL PROTECTED] (Roy Arends) writes: This is not the case for RIPE (194.in-addr.arpa). RIPE uses e=3 for both ZSK and KSK. Hence an emergency trust anchor roll is needed. i'd argue that if 194.in-addr.arpa is not registered a DLV registry and if in-addr.arpa is not itself signed, then the community of beneficiaries of 194's signedness is so small that this cannot be called an emergency. I wouldn't use a dlv registry. All dlv.isc.org's DNSKEYs have e=3. ;) Roy . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
