Re: [TLS] Proposed text for removing renegotiation (Martin Rex) Fri, 06 June 2014 22:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B56861A02AA for <>; Fri, 6 Jun 2014 15:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NQwtz47i6f7F for <>; Fri, 6 Jun 2014 15:30:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 951A21A0273 for <>; Fri, 6 Jun 2014 15:30:56 -0700 (PDT)
Received: from by (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: <>
To: Brian Smith <>
Date: Sat, 07 Jun 2014 00:30:45 +0200
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: <>
X-SAP: out
Cc: "" <>
Subject: Re: [TLS] Proposed text for removing renegotiation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jun 2014 22:30:59 -0000

Brian Smith wrote:
> Martin Rex <> 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: