IETF Logo Mail Archive

Re: [TLS] Proposed text for removing renegotiation

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 28 May 2014 17:46 UTC

Return-Path: <dkg@fifthhorseman.net>
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 318B51A6EE4 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 10:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JumuU-74hfiC for <tls@ietfa.amsl.com>; Wed, 28 May 2014 10:46:53 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5FE1A6EF0 for <tls@ietf.org>; Wed, 28 May 2014 10:46:45 -0700 (PDT)
Received: from [10.70.10.60] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id ECA73F986; Wed, 28 May 2014 13:46:39 -0400 (EDT)
Message-ID: <538620F3.6060605@fifthhorseman.net>
Date: Wed, 28 May 2014 13:46:27 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp> <CABkgnnUrMpmUH7DBgoZUAofe4J6PqNfYn9ORcmwu4385VAUX5g@mail.gmail.com> <CABcZeBMOCxBaas+9gCHPsPEGNOqAenUDTVx=+cS03E5pRXSPqw@mail.gmail.com>
In-Reply-To: <CABcZeBMOCxBaas+9gCHPsPEGNOqAenUDTVx=+cS03E5pRXSPqw@mail.gmail.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="X1EKi6pfgsWa1bO7tO48gdRCe7oks1bIP"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A6IY728tgR8IUvf3jX-9DQYc6C0
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: Wed, 28 May 2014 17:46:57 -0000

On 05/28/2014 01:23 PM, Eric Rescorla wrote:
> On Wed, May 28, 2014 at 10:02 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
> 
>> On 27 May 2014 17:44, 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's a good point.  Something that I missed.  A resumption handshake
>> would have to include an epoch from the previous session.  That number
>> would need to be incremented with each update of the master secret.
> 
> That's one option. The other option is just to flush your session cache.

I'm not sure i understand this argument properly, but:

> To
> the best of my knowledge, systems generally either have a lot of connection
> setups (which makes session caching attractive) or long-lived connections
> (where you would want to change keys) but usually not both.

Doesn't the classic XMPP server case have both?  there are a lot of c2s
connection setups which could benefit from session caching, and several
long-lived connections for the s2s connections which could benefit from
being able to re-key.

	--dkg

v2.23.0 | Report a Bug | By Email