Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP
Martin Rex <mrex@sap.com> Thu, 20 January 2011 00:51 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F933A7069 for <tls@core3.amsl.com>; Wed, 19 Jan 2011 16:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.165
X-Spam-Level:
X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHaYtTv4nOX0 for <tls@core3.amsl.com>; Wed, 19 Jan 2011 16:51:37 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 1C9BA3A7052 for <tls@ietf.org>; Wed, 19 Jan 2011 16:51:36 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0K0sCA3004685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 01:54:12 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201101200054.p0K0sBPh008067@fs4113.wdf.sap.corp>
To: mrex@sap.com
Date: Thu, 20 Jan 2011 01:54:11 +0100
In-Reply-To: <201101192215.p0JMFotX029338@fs4113.wdf.sap.corp> from "Martin Rex" at Jan 19, 11 11:15:50 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jan 2011 00:51:38 -0000
Martin Rex wrote: > > Wan-Teh Chang wrote: > > > > Another problem is how an RFC of a TLS feature references TLS. It > > usually references the latest version of TLS only. > > ... An implementor could be misled into thinking > > the TLS feature is only applicable to that version of TLS. > > While you're correct about a number of TLS-related documents ... I believe that some of the TLS related RFCs use the Obsolete/Update markers in a fashion quite different from how these markers are meant to be used. An a small error in that tagging, that appears to have started with rfc-4366, has propagated to other TLS-related RFCs. e.g. 4346, ->(4366), ->5246, ->6066 Quoting from RFC2223 "Instructions to RFC Authors" http://tools.ietf.org/html/rfc2223#section-12 Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. Obsoletes To be used to refer to an earlier document that is replaced by this document. This document contains either revised information, or else all of the same information plus some new information, however extensive or brief that new information is; i.e., this document can be used alone, without reference to the older document. For example, the defective "obsoletes" allegations of the base TLS protocol specs have adversely affected the third update of the TLS extensions document (rfc-6066). The second update transition of the TLS extensions document 3546->4366 was correct about the obsoletion (but is missing the update: marker) to implement TLSv1.0 with TLS extensions you can use RFCs 2246+4366 to implement TLSv1.1 with TLS extensions you can use RFCs 4346+4366 however 2246+6066 is insufficient to implement TLSv1.0 with TLS extensions and 4346+6066 is insufficient to implement TLSv1.1 with TLS extensions --you still need 4366 because the definition of the Extended Hello PDU is not part 6066. 6066 is an updated version of the "leftover parts" of 4366 that didn't make it into 5246--which bars it from obsoleting 4366. Overview of the header markings for some TLS documents: for the TLS Protocol documents: TLSv1.0 rfc-2246 - (OK) TLSv1.1 rfc-4346 shows (INVALID): Obsoletes: 2246 MISSING: Updates: 2246 TLSv1.1 rfc-5246 shows (INVALID): Obsoletes: 3268, 4346, 4366 shows (OK): Updates: 4492 MISSING: Updates: 2246, 3268, 4346, 4366 and for TLS Extensions documents: TLSext rfc-3546 shows (OK): Updates: 2246 TLSext rfc-4366 shows (OK): Obsoletes: 3546 MISSING: Updates: 2246, 4346 TLSext rfc-6066 shows (INVALID): Obsoletes: 4366 MISSING: Updates: 4366, 5246 TLS v1.0, TLSv1.1 and TLSv1.2 are protocol with small and subtle differences. But some of the information (like the Certificate handshake message PDU used by SSLv3,TLSv1.0,TLSv1.1) is not part of the TLS v1.2 spec (rfc-5246), so according to rfc-2223, the allegation of rfc-5246 to obsolete the TLSv1.0 and TLSv1.1 _spec_documents_ is clearly invalid. An example of correct obsoletion is the three (base) HTTP protocol specs: rfc1945 HTTP/1.0 @PROPOSED rfc2068 HTTP/1.1 @PROPOSED rfc2616 HTTP/1.1 @DRAFT (Obsoletes: 2068) to implement HTTP/1.0 you only need 1945, and to implement HTTP/1.1 you only need 2616, therefore 2068 meets the rfc2223 definition of Obsolete. Now there is an irony to this. The incorrect markers on rfc-4346 appear to have started the problem for the TLS-related documents. And it is exactly the document header of rfc-4346 with the invalid Obsolete: marker that gets used for illustration of document header formatting in rfc-5741: http://tools.ietf.org/html/rfc5741#page-4 -Martin
- [TLS] Unfortunate current practices for HTTP over… Adam Langley
- Re: [TLS] Unfortunate current practices for HTTP … Martin Rex
- Re: [TLS] Unfortunate current practices for HTTP … Michael D'Errico
- Re: [TLS] Unfortunate current practices for HTTP … Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] Unfortunate current practices for HTTP … Yngve N. Pettersen (Developer Opera Software ASA)
- [TLS] AES and SSLv3 (was Re: Unfortunate current … Michael D'Errico
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Martin Rex
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Wan-Teh Chang
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Tim Dierks
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Martin Rex
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Tim Dierks
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Marsh Ray
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Wan-Teh Chang
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Martin Rex
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Martin Rex
- Re: [TLS] AES and SSLv3 (was Re: Unfortunate curr… Martin Rex