Re: [TLS] Proposed text for removing renegotiation

Watson Ladd <watsonbladd@gmail.com> Sat, 07 June 2014 14:59 UTC

Return-Path: <watsonbladd@gmail.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 3AB7F1A00C3 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 07:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 BU-kS779Jve4 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 07:59:04 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CEA1A00D7 for <tls@ietf.org>; Sat, 7 Jun 2014 07:59:04 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id q107so6746518qgd.38 for <tls@ietf.org>; Sat, 07 Jun 2014 07:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ud3lPuT25+NObIn6KD22FmZsSTf5ezTqux8QfeO3V18=; b=0e2CNDrjxaPW/OZbE5PlZnU29mXCdt+e8r5nz02AvA03LKhP4nCMUjZqKlTgl4SeZy dt3gpc/3zSS/ssQQMmaXV3gl+ZuAy9yG+a+pWGBl2TxuUOJBGZ96eNvgGCFGgOfOVvbH pV4ZimDqic2L93HcD6JR3BIeM0iCT1LahqckR5X6r9GlaL/2wn7hyrSTFl8dNyu60Ovi pzOgVRjOSyRq47Nt6FVNK9QgmVbTxnvoa621eXwX/skHUoo0LGQp5MaTe4TYh7DGHrz+ pT0p02C76FF35oaWB75Nvk6BVO2kveQYhDPkRmiI5AIFV+ubH9oNjuFAR0Yj2U8QdYRc 1EOA==
MIME-Version: 1.0
X-Received: by 10.236.81.10 with SMTP id l10mr1400481yhe.18.1402153137090; Sat, 07 Jun 2014 07:58:57 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Sat, 7 Jun 2014 07:58:56 -0700 (PDT)
In-Reply-To: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp>
References: <CAFewVt65X1V6=A_HP_pcg=6nXNVFLxQmSsPB2rq1KvmGPRz+og@mail.gmail.com> <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp>
Date: Sat, 7 Jun 2014 07:58:56 -0700
Message-ID: <CACsn0cmcc6kXvOuqkZaDj7+QPdpY9qqQ58bs3s-JBGXdNJSZyw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G7iYIHIt8p51JXC4YOxC9R5A8Zs
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
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: Sat, 07 Jun 2014 14:59:08 -0000

On Fri, Jun 6, 2014 at 3:30 PM, Martin Rex <mrex@sap.com> wrote:
> 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:

What about this solution: separate TLS into a handshake and transport.
The handshake computes a connection key associated with the ticket,
then the transport computes a transport key based on that key and some
conceptually separate random data from both sides exchanged in the
handshake. When the transport is exhausted or we resume, the random
numbers change, but the connection key does not.

>
>   CVE-2010-3864     http://www.openssl.org/news/secadv_20101116.txt
>   CVE-2010-4180     http://www.openssl.org/news/secadv_20101202.txt
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin