Re: [TLS] OPTLS: Signature-less TLS 1.3

Manuel Pégourié-Gonnard <> Sat, 01 November 2014 23:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E0081A1BA9 for <>; Sat, 1 Nov 2014 16:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jYY5DDOt10HG for <>; Sat, 1 Nov 2014 16:43:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 410281A1BA7 for <>; Sat, 1 Nov 2014 16:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=zEG430W7bSo5qiyt4OHY2iEDmVKi/N6pwq02HD0FBDs=; b=A7m7S4e0yWMwbvhvv8+lblPzjEd6nVDqlB2Dq2EsguMt0a+tEhZCaMKnZeMP1Bkgv4qqfgSac+IRCB27LHnWxY23l5PpgQO2aFcQvALgQ9K59/GHedYEgG0EAHkIRgyEQmP8eVGZaghUb50W6IwkGbUDtYbX3tC34GL+SCv3Z7U=;
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1XkiKM-000719-BM; Sun, 02 Nov 2014 00:43:26 +0100
Message-ID: <>
Date: Sun, 02 Nov 2014 00:43:31 +0100
From: Manuel Pégourié-Gonnard <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Eric Rescorla <>, Watson Ladd <>
References: <> <> <20141101101611.GA25180@LK-Perkele-VII> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on
Cc: "" <>, Hoeteck Wee <>
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
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: Sat, 01 Nov 2014 23:43:36 -0000

On 02/11/2014 00:22, Eric Rescorla wrote:
> On Sat, Nov 1, 2014 at 3:22 PM, Watson Ladd <> wrote:
>> Why does the duration of the validity of
>> the response affect the existence of this issue?
> My argument here is that clients have some ability to sanity check
> network time information, and so it's not necessarily like the attacker
> can set the time to anything (I don't know how NTP clients currently
> work). So an attacker who can only move the clock by a day or
> two is going to of course be more effective attacking credentials
> with a short time window than with a long time window
> (though arguably that's because the latter is less secure to start
> out with).
> Does that make sense?
I think it does, at least partially

I'm by no means an expert on NTP security, but in my small experience, I've seen
configurations on laptops where the NTP server is started when a network
connection is established, and with an option that abruptly sets the time
(rather than slowly shifting it) on startup (that's the -s option to openntpd
for example).

So, while I tend to agree that in theory clients could be able to sanity-check
the network time if a precision of the order of days is desired, I'm afraid in
practice it's not happening everywhere.

But sure, needing a higher level of precision can only make more attacks
practical in more circumstances.