Re: [TLS] Followup on Update

Martin Thomson <> Wed, 25 February 2015 03:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 731121A1A04 for <>; Tue, 24 Feb 2015 19:45:08 -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 mgcf_noU7AwT for <>; Tue, 24 Feb 2015 19:45:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A2571A0266 for <>; Tue, 24 Feb 2015 19:45:07 -0800 (PST)
Received: by with SMTP id uz6so1300957obc.9 for <>; Tue, 24 Feb 2015 19:45:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ombWCNy8JKDvCgOLQFoT4PEfwwSnblvTNqPfMAE+cNA=; b=VN/qtM5sDuV/qsj5n8646ydamPT3gEanE37L5v142kiypyGczDqTemAgdwZzq1cQlg IZg+ZxXGSZvFgTrS4KSl18ZttXOnxiWXji79Dw3TDFo2+WXAU43rsDLJfavXB0BqChV9 dlxRLDzSxCRGX32hQsIa1Dq7RTdrLdJoh/tKnSc6IaLNhzEjdBfccwSQ8SrIalv08Nw7 a03xP+LfU67DHnRnkYgrnf64FH8cPS39LewI9KxJ550MY/CP8nhCTZG/8W7oRX5SAscX pzBLAkRNk7GEc6pKJNjPULApiB1P54VcCGfKQO9UhFbNvPrC5DgR2EGDMLpXVDL5j+VN Ugpg==
MIME-Version: 1.0
X-Received: by with SMTP id s188mr758232oib.94.1424835905346; Tue, 24 Feb 2015 19:45:05 -0800 (PST)
Received: by with HTTP; Tue, 24 Feb 2015 19:45:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 25 Feb 2015 16:45:05 +1300
Message-ID: <>
From: Martin Thomson <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
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 03:45:08 -0000

On 25 February 2015 at 15:00, Eric Rescorla <> wrote:
> As a minor nit, it's kind of a pain to say every M minutes because
> often TLS stacks are driven by the application and don't have internal
> timers, but you could of course say "first record after M minutes"
> which would (probably) be close enough.

In addition to this, it seems like more of a policy decision that is
driven more by circumstance than any direct security requirement.

We might recommend that rekeying occur for long sessions, but it's
hard to pick a one-size-fits-all value to recommend.  As low as 10
minutes might be appropriate for high-value, high-volume data; whereas
an IoT device with low-value, low-volume data might be content with
rekeying only for the purposes of session extension (i.e., on a scale
of days or weeks).

As proposed, there is no significant security benefit to the Update
protocol other than to stave off key exhaustion.  I think that's a
fine thing on its own merits, but I don't think we need to place too
much weight on the mechanism.