Re: [TLS] Let's remove gmt_unix_time from TLS

Martin Thomson <> Mon, 09 December 2013 19:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F12031AE50F for <>; Mon, 9 Dec 2013 11:54:20 -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 B5hYI0Go5gHa for <>; Mon, 9 Dec 2013 11:54:18 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::235]) by (Postfix) with ESMTP id 969CD1AE07F for <>; Mon, 9 Dec 2013 11:54:18 -0800 (PST)
Received: by with SMTP id x55so3922125wes.40 for <>; Mon, 09 Dec 2013 11:54:13 -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=emw2FRBHcfdKWnWq8uk4wRnKdjhOBtU5S8jr0pJK+fA=; b=CsnYdTQnXJVavQ18s5DQvDaOER/KirLXzrVJz4c4f0qHjUtNn3khvGp9Rvb/a/+Z7/ BM3WrIZ9ufQj7FIAXmvL6R+1+dlDpS5tI/iz8K+7+aDCTVVtKV25g0jGP//QX6fgA8OB hxFUCYbQkK4y5A8cRbDoRwFpi4BVmnohyWZ7o1Sw3xGxmipKG9bd2N6CJmz9masu8C58 yBgEDOZ5vVE0HYk1xIZ0+XX4P5RX9JKsCbd9K2HyF8+PnEOfWdl9cg56lTJhuYi775k3 tcoIO0BOkzZna9WlPquFDSPcnqLLLxs7FAff9+wbkdCruFFCzz0OodR7OjpmlR6+YqLU LzCw==
MIME-Version: 1.0
X-Received: by with SMTP id fj6mr15670990wib.58.1386618853274; Mon, 09 Dec 2013 11:54:13 -0800 (PST)
Received: by with HTTP; Mon, 9 Dec 2013 11:54:13 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 9 Dec 2013 11:54:13 -0800
Message-ID: <>
From: Martin Thomson <>
To: Nick Mathewson <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
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: Mon, 09 Dec 2013 19:54:21 -0000

On 9 December 2013 10:49, Nick Mathewson <> wrote:
> On the latter point, I'd suggest that rounding is a little better than
> adding random skew, since only a smaller fraction of a client's
> declared times will leak anything about the client's skew.
> Randomize-and-round might be better still, though I'm afraid I haven't
> worked through the full analysis.

It depends on what you believe you are protecting against, but if you
intend to protect against revealing the value of the local clock, then
neither is sufficient.  It all depends on how many samples your
adversary has available.

With rounding, all you need to recover the time is to watch for edge
crossings and align them.  With randomization, you ultimately reveal
time by hitting the limits of the random space.  9 bits of space
doesn't require a lot of samples.

If you want to do a really good job, then a 1-dimensional application
of the methods described in
would most likely work.  I'd probably go with full random before I
went there though - maintaining more secrets sounds like a good way to
get in trouble.