Subject: [TLS] [Technical Errata Reported] RFC5246 (2643)

From: RFC Errata System <[email-masked]>
Date: Mon, 22 Nov 2010 21:20:57 -0800 (PST)

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=2643

--------------------------------------
Type: Technical
Reported by: Matt McCutchen <[email-masked]>

Section: E.3

Original Text
-------------
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 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).

Corrected Text
--------------
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
bytes are not all 0x03.  If they are, 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).

Notes
-----
The condition is the wrong way around.  When the bytes *are* all 0x03, that means the client supports TLS, so there must have been a version rollback attack in order for SSL 2.0 to be negotiated.  For example, see the NSS implementation (line number may rot):

https://mxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslcon.c#1695

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date    : August 2008
Author(s)           : T. Dierks, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 28 Nov 2010 19:08:52 -0800

Does it make sense to clarify how SSL 2.0 should be supported while we're
simultaneously saying SSL 2.0 MUST NOT be negotiated?

Mike

                          Prohibiting SSL Version 2.0
                       draft-turner-ssl-must-not-02.txt

Abstract

    This document requires that when TLS clients and servers establish
    connections that they never negotiate the use of Secure Sockets Layer
    (SSL) version 2.0.  This document updates the backward compatibility
    sections found in the Transport Security Layer (TLS) Protocol, RFC
    5246.

---

From: Marsh Ray <[email-masked]>
Date: Sun, 28 Nov 2010 21:28:37 -0600

> draft-turner-ssl-must-not-02.txt

I think it does.

Errors are errors and it adds value to correct them, even for things 
that we wish would go away. RFCs can be used to interpret data which was 
written in the past.

- Marsh