Re: [TLS] Followup on Update

Dave Garrett <> Wed, 25 February 2015 05:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C13651A9096 for <>; Tue, 24 Feb 2015 21:09:13 -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 7-Nfpjgy1THw for <>; Tue, 24 Feb 2015 21:09:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFA281A1B88 for <>; Tue, 24 Feb 2015 21:09:11 -0800 (PST)
Received: by with SMTP id hq11so570306vcb.9 for <>; Tue, 24 Feb 2015 21:09:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=5BYIzrORYOxttcLE+FCXADRUD+WDbyev9jTbeDwOwyk=; b=UDPVqR38S7BK/hf5GXlOyGLUjWaJ6Y8bBU9JMHToPWnVKVXksfhO3Wnh+XiH7Y3Roj ipRF8ZQOYsWD8NZm86tztq2Alzgf4Mqng2Ta93KnoFjzVzUhkOGApMeN7hBx7tlV2QBr 7WpyYVTi9a7tyxUrsgs/9FbBtQPSgkeikrnVENTaxvbFXQfpc5Y5ILIxeo20tYwBKf4q jJsyUQSlKCOZ6I16aZOSQAOhgRz8lMawN/3cDItRW0gU19y1pM4VMaGb9za8rrQNCdQn yeSHzR30ut9jWXDtPja1iDLO4c3J3AxkhCVW/qyCssnSdAV1Gj7dAIPmeHMyYUk0ZCCY 6rGQ==
X-Received: by with SMTP id np12mr2109327vdb.92.1424840951055; Tue, 24 Feb 2015 21:09:11 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id ww6sm5187663vdc.21.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Feb 2015 21:09:10 -0800 (PST)
From: Dave Garrett <>
To: Eric Rescorla <>
Date: Wed, 25 Feb 2015 00:09:08 -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: <>
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 05:09:13 -0000

On Tuesday, February 24, 2015 09:00:46 pm Eric Rescorla wrote:
> On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett <>
> wrote:
> > On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote:
> > > [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.
> It's not entirely clear that we know how to design a good heuristic here,
> especially one that covers the entire range of possible algorithms.

That's sort of my point; this proposal requires implementations to do so.
I'm saying that picking one in the spec would be preferable to leaving it
up to the whims of whatever the many combinations of implementations
end up deciding. Even if some use-case needs to add rekeys, starting
from a conservative heuristic in the spec would ensure implementations
are provided with at least a general expectation of how to use this.

> 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.

I'm not suggesting a precise heuristic here; just some semi-regular interval
that would be more specific than "MAY ... at any time". With it left as vague
as proposed, you could get deployments that never rekey or ones that
decide to rekey stupidly frequently. (DoS risk if not implemented
efficiently?) Picking any arbitrary interval would make things simpler and
ensure that this feature is used sufficiently.

The simplest route is to just specify a number of records to rekey after.

> > This would also ensure entropy for rekeying comes from both endpoints
> > equally over the course of the connection.
> Can you explain more about why that's an important consideration?

It's just something that occurs to me with the current proposal. It allows
for one sided rekeys, whereas the handshake gets randomness in each
hello from each endpoint. It just strikes me as notably different to rely on
just the one source of entropy here (plus previous).

It's a "huh, interesting" thought not a "oh, that's horrible" thought.

> > 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)
> The algorithm in this document is intended to be safe in the case of both
> simultaneous
> and (I believe) pipelined updates. I'd be interested in knowing if it's not.

Yes, I don't think it's a spec risk. An implementation risk is possible, though.

It's a new feature that could end up with a new setting for an admin to
fiddle with that probably doesn't need to be highly variable to do the job.
Or put another way, it's a feature that I'm overthinking about the possibility
of implementations overthinking how to use it. ;)