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