RE: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks)

[<Pasi.Eronen at nokia.com>]

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 at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls