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

[<Pasi.Eronen at nokia.com>]

Martin Rex wrote:

> I once had to analyze a handshake problem with a particular's vendor
> SSL accellerator (server-side middle-box), where that box contained
> an error in the RSA encryption and every once in a while sent garbage,
> i.e. there was no recognizable PKCS#1 padding when RSA-decrypting
> on the backend server.  I was lucky that our SSL implementation did
> not use the OpenSSL approach, where this kind of error is not only
> hidden from the peer, but also from the local caller.
> 
> Completely hiding the decryption failure from the local caller
> creates a serious supportablility issue, so please be more careful
> with the recommendation.  One should be careful, though, that the
> local error reporting, which may be as simple as setting an integer
> value to a particular value, does not result in a measurable timing
> difference.  It is important that the local caller is able to
> retrieve the real reason why the session establishment failed,
> not "MAC failure" (as the SSL alert on the wire suggests") but
> RSA-decryption failure.

I do agree that such debugging features are useful in many 
circumstances -- but there are other channels than timing
that may leak information. How about rephrasing this:

   "Care must also be taken to avoid leaking information about
   the error situation via log files, or other channels."

as follows:

   "It may be useful to log the real cause of failure for
   troubleshooting purposes; however, care must be taken to 
   avoid leaking the information the attacker (though, e.g.,
   timing, log files, or other channels)."

Best regards,
Pasi

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls