Re: [TLS] Proposed text for removing renegotiation

mrex@sap.com (Martin Rex) Fri, 06 June 2014 22:30 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56861A02AA for <tls@ietfa.amsl.com>; Fri, 6 Jun 2014 15:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQwtz47i6f7F for <tls@ietfa.amsl.com>; Fri, 6 Jun 2014 15:30:56 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951A21A0273 for <tls@ietf.org>; Fri, 6 Jun 2014 15:30:56 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s56MUjMq028572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Jun 2014 00:30:45 +0200 (MEST)
In-Reply-To: <CAFewVt65X1V6=A_HP_pcg=6nXNVFLxQmSsPB2rq1KvmGPRz+og@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Date: Sat, 7 Jun 2014 00:30:45 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fCAXeuF_dKDxfsczwWWqCspS6OE
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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: Fri, 06 Jun 2014 22:30:59 -0000

Brian Smith wrote:
> Martin Rex <mrex@sap.com> wrote:
>>
>> Conceptually, the TLS session cache is readonly after an entry
>> is created, and that is GOOD, i.e. full TLS handshakes create new,
>> distict session cache entries, and abbreviated TLS handshakes resume
>> existing session cache entries and *NEVER* modify them.
> 
> That is not true. During session resumption, the server can send a new
> session ticket for the existing session and the client has the option of
> adding the new ticket to the session (and removing the old ticket).
> 
> Also often timestamps (e.g. for LRU replacement bookkeeping) and/or
> counters (e.g. for cache hit rate statistics) in a session are updated
> during resumption, though these are "just" implementation issues.


With "conceptually", I referred to the requirements of the specification,
not to the details of certain implementations of it.  Counting how often
sessions are resumed is nothing that the spec requires, and how you
manage your cache entries (expiration) is not in scope of that concept.

When the read-only concept is violated, and implementations start scribbling
over _state_ of sessions that are in the cache during resumption
handshakes, it may result in problems such as these:

  CVE-2010-3864     http://www.openssl.org/news/secadv_20101116.txt 
  CVE-2010-4180     http://www.openssl.org/news/secadv_20101202.txt


-Martin