Thierry Moreau wrote:
> Dear Roy:
>
> Thanks for setting the record straight. See below for a suggestion as
> possible workaround in the BIND application for the OpenSSL weakeness
> for RSA signature verification with the public exponent=3.
>
> Roy Arends wrote:
>
>>
>> On Sep 8, 2006, at 5:08 PM, Thierry Moreau wrote:
>>
>>>
>>> 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
>>
>>
>> BIND uses openssl. There is a check during configure if the version
>> is 0.9.5a or higher. I guess it should be either at least 0.9.7k or
>> 0.9.8c for upcoming releases.
>>
>>> 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).
>>
>>
>> The issue here is not passing the erroneous length indication to
>> openssl. The issue is that openssl did not check if the pkcs padding
>> was long enough so that len(00 01 FF*) is equal to len(modulus)-288
>> before removing the padding, thus allowing trailing garbage. There is
>> nothing that BIND or DNSSEC input reconstruction can do here in order
>> to circumvent the issue in openssl, since the padding itself will
>> only be visible after the RRSIG signature payload is decrypted. The
>> padding is then subsequently removed, and the hash is matched with
>> the hash over message. All this is outside the scope of isc's named.
>
> "the padding itself will only be visible after the RRSIG signature
> payload is decrypted"
>
> actually, to be more accurate, this should read:
>
> "the padding itself will only be visible after the RRSIG signature
> payload is passed to the RSA encryptin function with the public
> signature key"
>
> and this leads to the suggestion below.
>
>>
>>>
>>> If it (BIND + deployed SEP KSKs) isn't broken, don't fix it as an
>>> emergency response to a false alarm.
>>
>>
>> it is broken.
>>
>
> I agree.
>
> Here is a suggestion for a workaroud in BIND as an OpenSSL appication:
>
> From the RSA public signature key, make a temporary RSA public
> encryption key (I don't know the OpenSSL API details, but key usage
> integrity is typically enforced by a crypto library, so the {DNSKEY RR
> conversion to OpenSSL RSA public signature key object} can be followed
> by a {DNSKEY RR conversion to OpenSSL RSA public encryption key object}
> using the same RSA modulus and exponent from the DNSKEY RR contents).
>
> Ask OpenSSL to encrypt the RRSIG signature payload with the temporary
> RSA public encryption key.
>
> Check that the padding length is adequate.
>
> This workaround in the BIND application is obviously neither a
> substitute for OpenSSL upgrade nor an endorsement of any public exponent
> 3 in any operational use of RSA cryptosystem. But it might assist the
> reduction of vulnerable portion of DNSSEC deployed technology (BIND
> version and OpenSSL version at the resolver side, DNSSEC RR public
> exponent values=3 anywhere along the chain of trust).
>
> This workaround idea is available to any application using OpenSSL. Feel
> free to circulate it in any other application forum.
You don't need to work around it, since OpenSSL has been fixed for
nearly a week now.
--
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