Subject: [TLS] Issue 26: implementation pitfalls

From: <[email-masked]>
Date: Wed, 25 Jul 2007 20:50:17 +0300

I promised to write a first draft for a "implementation pitfalls"
appendix; comments are welcome.

Best regards,
Pasi

D.4 Implementation Pitfalls

Implementation experience has shown that certain parts of earlier
TLS specifications are not easy to understand, and have been a
source of interoperability and security problems. Many of these
areas have been clarified in this document, but this appendix
contains a short list of the most important things that require
special attention from implementors.

TLS protocol issues:

o  Do you correctly handle handshake messages that are fragmented
   to multiple TLS records (see Section 6.2.1)? Including corner
   cases like a ClientHello that is split to several small
   fragments?

o  Do you ignore the TLS record layer version number in all TLS
   records before ServerHello (see Appendix E.1)?

o  Do you handle TLS extensions in ClientHello correctly,
   including omitting the extensions field completely?

o  Do you support renegotiation, both client and server initiated?
   While While renegotiation this is an optional feature,
   supporting renegotit is highly recommended.

Cryptographic details:

o  In RSA-encrypted Premaster Secret,  do you correctly send and 
   verify the version number? When an error is encountered, do 
   you continue the handshake to avoid the Bleichenbacher 
   attack (see Section 7.4.7.1)?

o  What countermeasures do you use to prevent timing attacks against
   RSA decryption and signing operations (see Section 7.4.7.1)?

o  When verifying RSA signatures, do you accept both NULL and
   missing parameters (see Section 4.7)? Do you verify that the
   RSA padding doesn't have additional data after the hash value?
   [FI06]

o  When using Diffie-Hellman key exchange, do you correctly strip
   leading zero bytes from the negotiated key (see Section 8.1.2)? 

o  Does your TLS client check that the Diffie-Hellman parameters 
   sent by the server are acceptable (see Section F.1.1.3)?

o  How do you generate unpredictable IVs for CBC mode ciphers
   (see Section 6.2.3.2)? 

o  How do you address CBC mode timing attacks (Section 6.2.3.2)?

o  Do you use a strong and, most importantly, properly seeded
   random number generator (see Appendix D.1) for generating the
   premaster secret (for RSA key exchange), Diffie-Hellman private
   values, the DSA "k" parameter, and other security-critical
   values?

(and add to references)

[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based
on implementation error", [email-masked] mailing list, 27
August 2006,
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html.

(end)

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 25 Jul 2007 19:18:16 +0100

>    RSA padding doesn't have additional data after the hash value?

A variation on the attack is to include additional data in the middle
of the structure for example via a parameter.

That might be covered by saying NULL and missing parameters *only*
though a decoder that accepted invalid content octets in a NULL value
would still be vulnerable.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.