Re: [TLS] Followup on Update

Dave Garrett <> Wed, 25 February 2015 01:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 250FE1A8881 for <>; Tue, 24 Feb 2015 17:43:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NJ4TlZO6uHdi for <>; Tue, 24 Feb 2015 17:43:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA8D01A877F for <>; Tue, 24 Feb 2015 17:43:53 -0800 (PST)
Received: by with SMTP id im6so301628vcb.11 for <>; Tue, 24 Feb 2015 17:43:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=bO6N7KPc36EEqCQ4pdKZdkyoRkjT/cSCYy+TO0UcbRE=; b=z62MDxcnXnbTxZvWw3XaYkEL9MRt+2rQVXeFQC5nRFyPfNU+Q4gyGjpwDZvDAVgxRF 7Ywz4s6HqmJ5qvw/x1VG2ejudsyAClti+efHORf6peWRbJKG36BltE0QTld85XSPpyW5 IcUltklhfJgAB2Qi+c4CEiuFbSO+X5MavBpTDhQ2VjQTSMLPvYVaLbLTGMqILkxeQW90 u0t+f8Mz0uXX6CJaxGCawuzvW1SGxVWpbp9jIBfayuWGEkeX/QR2zlOC24xl3MkWU3XR jkcvv5v63APcQz4iAFjrDXVaceXMdB+j7EMEgXb39MVE0D98SSlkqSkf28lNWlUazqJc DXfg==
X-Received: by with SMTP id vv8mr1142251vdb.64.1424828632889; Tue, 24 Feb 2015 17:43:52 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id rt15sm5618990vdb.12.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Feb 2015 17:43:51 -0800 (PST)
From: Dave Garrett <>
To:, Eric Rescorla <>
Date: Tue, 24 Feb 2015 20:43:49 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; )
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] Followup on Update
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: Wed, 25 Feb 2015 01:43:55 -0000

On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote:
> Folks,
> I'd like to get a sense of the WG on whether they want to pursue the Update
> mechanism [0].
> There are several possibilities here, including:
> - Just do basic Update
> - Move session ticket establishment to Update
> - Mode client authentication to Update
> My sense from the discussion in HNL was that people were generally
> positive on basic Update and unsure on the other two. If that's right,
> I'll buff up PR#94 for merge into the spec (pending chair approval).
> Thanks,
> -Ekr
> [0] See for a WIP
> version of the basic mechanism.

The current proposal says:

"An implementation MAY send an UpdateRekey at any time after
the handshake completes."

Is there a particular reason to not just have an automatic rekey at semi-regular intervals? So, every N records or M minutes (or whichever comes first) an endpoint must send a rekey, and then after a similarly measured interval the other endpoint sends a rekey; repeat ad infinitum. This would also ensure entropy for rekeying comes from both endpoints equally over the course of the connection. I would expect it would be better to not rely on implementations all designing their own heuristics on when to send rekey updates, and also would avoid multiple updates being sent at the same time by each endpoint (and the possible pitfalls of doing so).