RE: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks)
<Pasi.Eronen@nokia.com> Mon, 27 November 2006 13:05 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogBD-0008KI-T2; Mon, 27 Nov 2006 08:05:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogBC-0008IJ-LV for tls@lists.ietf.org; Mon, 27 Nov 2006 08:05:50 -0500
Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogB8-00022g-RI for tls@lists.ietf.org; Mon, 27 Nov 2006 08:05:50 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kARD5Sj2030656; Mon, 27 Nov 2006 15:05:44 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 15:05:11 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 15:05:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks)
Date: Mon, 27 Nov 2006 15:05:14 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F240374881B@esebe105.NOE.Nokia.com>
In-Reply-To: <7.0.1.0.2.20061101091038.0208f420@nist.gov>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks)
Thread-Index: Acb9wgSf1EKVbyKaR12QoVxxwPw3hAUYMLgw
From: Pasi.Eronen@nokia.com
To: ray.perlner@nist.gov, tls@lists.ietf.org
X-OriginalArrivalTime: 27 Nov 2006 13:05:10.0209 (UTC) FILETIME=[AB1A2B10:01C71224]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::061127150544-7664FBB0-37743F0C/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
Ray Perlner wrote: > Page 62: Section 7.4.9.1 under Note: This section suggests a > procedure to prevent the Bleichenbacher attack on PKCS#1 v1.5 > encrypted messages (specifically the pre-master secret.) This > procedure is not listed as mandatory. We recommend that either this > procedure be made mandatory, or that all RSA encrypted messages be > required to use the OAEP padding scheme specified in PKCS#1 v2. In > the latter scenario, the overwhelming majority of PKCS#1 v1.5 > formatted messages would need to be rejected by any compliant > implementation. > > There is ANOTHER note later in this section (at the very end, after > the implementation notes) that discusses a variant of the > Bleichenbacher attack (by Klima, Pokorny, and Rosa - see [KPR03]) > that depends on the server reporting on errors found in the version > number included in the RSA-decrypted premaster-secret > message. Therefore, the draft's weak statement to the effect that > servers shouldn't generate an alert if there is such a problem > should also be strengthened to a MUST NOT. In fact, it should be a > general rule that decryption problems with PKCS #1.5-formatted > messages MUST NOT trigger actions that are observably different than > the actions that would be taken if there were no problems. Hmm... IMHO this section, as its currently written, doesn't offer enough guidance for an implementer to get it right. Furthermore, the text in Appendix E.2 (about what TLS-capable servers should do in SSL 2.0 compatibility mode) confuses things even further (and seems to ignore the existence of Bleichenbacher/Klima attacks). Then there's the issue on what the spec should say about checking the version number in PreMasterSecret. Currently, it simply says "Client implementations MUST and Server implementations MAY check the version number", which is IMHO a bit vague. Here's a suggested rephrasing for the first and fourth note in Section 7.4.9.1: Note: The version number in the PreMasterSecret is the version offered by the client in the ClientHello.client_version, not the version negotiated for the connection. This feature is designed to prevent rollback attacks. Unfortunately, some old implementations use the negotiated version instead and therefore checking the version number may lead to failure to interoperate with such incorrect client implementations. Client implementations MUST always send the correct version number in PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, server implementations MUST check the version number as described in the note below. If the version number is earlier than 1.0, server implementations SHOULD check the version number, but MAY have a configuration option to disable the check. Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. [KPR03] can be used to attack a TLS server that reveals whether a particular message, when decrypted, is properly PKCS#1 formatted, contains a valid PreMasterSecret structure, or has the correct version number. The best way to avoid these vulnerabilities is to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks. In other 1. Generate a string R of 46 random bytes 2. Decrypt the message M 3. If the PKCS#1 padding is not correct, or the length of message M is not exactly 48 bytes: premaster secret = ClientHello.client_version || R else If ClientHello.client_version <= TLS 1.0, and version number check is explicitly disabled: premaster secret = M else: premaster secret = ClientHello.client_version || M[2..47] In any case, a TLS server MUST NOT generate an alert if processing an RSA-encrypted premaster secret message fails, or the version number is not as expected. Instead, it MUST continue the handshake with a randomly generated premaster secret. Care must also be taken to avoid leaking information about the error situation via log files, or other channels. The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure against the Bleichenbacher attack. However, for maximal compatibility with earlier versions of TLS, this specification uses the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known to exist provided that the above recommendations are followed. And rewrite appendix E.2 as follows (changing SHOULD to MUST for sending the 0x03 padding): E.2. Avoiding man-in-the-middle version rollback When TLS clients fall back to Version 2.0 compatibility mode, they MUST use special PKCS#1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients. When a client negotiates SSL 2.0 but also supports TLS, it MUST set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these eight padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match). Note that reporting the error situation to the client could make the server vulnerable to attacks described in [BLEI]. Comments? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] NIST TLS recomendations Ray Perlner
- [TLS] Re: NIST TLS recomendations Simon Josefsson
- Re: [TLS] Re: NIST TLS recomendations Peter Gutmann
- RE: [TLS] Re: NIST TLS recomendations Kemp David P.
- Re: [TLS] NIST TLS recomendations Bodo Moeller
- Re: [TLS] NIST TLS recomendations Bodo Moeller
- Re: [TLS] Re: NIST TLS recomendations Bodo Moeller
- Re: [TLS] NIST TLS recomendations Peter Gutmann
- Re: [TLS] Re: NIST TLS recomendations Peter Gutmann
- Re: [TLS] Re: NIST TLS recomendations Bodo Moeller
- RE: [TLS] Re: NIST TLS recomendations Pasi.Eronen
- Re: [TLS] Re: NIST TLS recomendations Bodo Moeller
- [TLS] Re: NIST TLS recomendations Simon Josefsson
- Re: [TLS] Re: NIST TLS recomendations Peter Gutmann
- Re: [TLS] Re: NIST TLS recomendations Bodo Moeller
- RE: [TLS] Re: NIST TLS recomendations Pasi.Eronen
- RE: [TLS] Re: NIST TLS recomendations Peter Gutmann
- Re: [TLS] Re: NIST TLS recomendations Bodo Moeller
- [TLS] Re: NIST TLS recomendations Simon Josefsson
- Re: [TLS] Re: NIST TLS recomendations Peter Gutmann
- RE: [TLS] NIST TLS recomendations (IV generation) Pasi.Eronen
- RE: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Pasi.Eronen
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Martin Rex
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Peter Gutmann
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Bodo Moeller
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Bodo Moeller
- RE: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Pasi.Eronen
- RE: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Pasi.Eronen
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Peter Gutmann
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Dr Stephen Henson
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Bodo Moeller
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Bodo Moeller
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Steven M. Bellovin
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Martin Rex
- Re: [TLS] NIST TLS recomendations (PKCS#1 encrypt… Peter Gutmann