Subject: [TLS] Fwd: [Technical Errata Reported] RFC2246 (3481)

From: Sean Turner <[email-masked]>
Date: Mon, 12 Aug 2013 16:49:12 -0400

Yes I know this is an errata against TLS 1.0, but should it be adopted?

spt

-------- Original Message --------
Subject: [Technical Errata Reported] RFC2246 (3481)
Date: Fri,  8 Feb 2013 14:01:22 -0800 (PST)
From: RFC Errata System <[email-masked]>
To: [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC2246,
"The TLS Protocol Version 1.0".

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

--------------------------------------
Type: Technical
Reported by: Martin Rex <[email-masked]>

Section: 8.1.2

Original Text
-------------
8.1.2. Diffie-Hellman

    A conventional Diffie-Hellman computation is performed. The

    negotiated key (Z) is used as the pre_master_secret, and is converted

    into the master_secret, as specified above.

Corrected Text
--------------
8.1.2. Diffie-Hellman

    A conventional Diffie-Hellman computation is performed.  The

    negotiated key (Z) is used as the pre_master_secret, and is converted

    into the master_secret, as specified above.  Leading bytes of Z that

    contain all zero bits are stripped before it is used as the

    pre_master_secret.

Notes
-----
Adopting the clarification from rfc4346 Section 8.1.2.  Not stripping 
the leading zero bits of Z will cause interop problems (handshake 
failures) with the installed base.  Rfc2246 is still the authoritative 
spec for TLSv1.0.  One can not implement TLSv1.0 from rfc4346.

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.

--------------------------------------
RFC2246 (no draft string recorded)
--------------------------------------
Title               : The TLS Protocol Version 1.0
Publication Date    : January 1999
Author(s)           : T. Dierks, C. Allen
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 12 Aug 2013 17:19:24 -0400

> Yes I know this is an errata against TLS 1.0, but should it be adopted?

Unless there are significant philosophical objects against adopting errata
for RFCs that have already been superseded, this should be adopted.
(There's an interoperable base of TLS 1.0 implementations that behave as
described.)

Bodo

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Aug 2013 23:21:04 +0200

> Yes I know this is an errata against TLS 1.0, but should it be adopted?

I think that fixing the spec for TLSv1.0 to match with what's deployed
would be quite useful, but this may be opening the floodgates since
there are so many issues.  Perhaps a 2246bis-document to describe
TLSv1.0 is an easier way to manage this.

/Simon

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

---

From: Sean Turner <[email-masked]>
Date: Mon, 12 Aug 2013 17:27:13 -0400

On 8/12/13 5:19 PM, Bodo Moeller wrote:
> On Mon, Aug 12, 2013 at 4:49 PM, Sean Turner <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Unless there are significant philosophical objects against adopting
> errata for RFCs that have already been superseded, this should be
> adopted. (There's an interoperable base of TLS 1.0 implementations that
> behave as described.)

Until we move an RFC historic or outright say don't use this one it's 
horribly broken, I think we have to keep dealing with errata.

spt