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

Watson Ladd <> Sat, 01 November 2014 22:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF9141A1B6C for <>; Sat, 1 Nov 2014 15:23:00 -0700 (PDT)
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 gBbWbQldthuM for <>; Sat, 1 Nov 2014 15:22:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11DFF1A1B51 for <>; Sat, 1 Nov 2014 15:22:58 -0700 (PDT)
Received: by with SMTP id 10so4222010ykt.21 for <>; Sat, 01 Nov 2014 15:22:57 -0700 (PDT)
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=YTBQP2bzCxDOs/4uRjzqR3rhHkpsFYB9d+mIN90uBdQ=; b=Cf0+A4gIGm1LPLUw7GJB58UbJWYQPmWfEGA52ZJItr04pyasdZSrBo7TCHWJcgnLi3 +ZZGzHZqsFK1yFiR1OwSdeFPxJESOty0EOwYS9uQJ+esMuumyrdGLCANf7d5djMmWGNk JKeUaH9ZfY7jqTHMZTIjn27bQolPndUgpe2NyneQEfSo6X/KEM0jgtN7I3V5MewyXZx7 ueUmWYXYo1wV6jF6Br0+w0DgLDTc3ZKEe3aKL1o0F72PBRV2q/LwXTK2Y0gMsjVU2Qji 6eND4wxOgwcQnuAtdOqJyhil6D5SgNUV0CMgjemagEAYF/EKPbmX8HJQ/zHdCrbVqos2 iUVA==
MIME-Version: 1.0
X-Received: by with SMTP id h81mr17432676ykc.55.1414880577381; Sat, 01 Nov 2014 15:22:57 -0700 (PDT)
Received: by with HTTP; Sat, 1 Nov 2014 15:22:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <20141101101611.GA25180@LK-Perkele-VII> <> <> <>
Date: Sat, 01 Nov 2014 15:22:57 -0700
Message-ID: <>
From: Watson Ladd <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
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 22:23:01 -0000

On Sat, Nov 1, 2014 at 2:45 PM, Eric Rescorla <> wrote:
> On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd <> wrote:
>> On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla <> wrote:
>> >
>> > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara
>> > <> wrote:
>> >>
>> >>
>> >> However, this poses some challenges with respect to revocation. From
>> >> what
>> >> I
>> >> understand, the parameters are intended to have limited lifetime (much
>> >> shorter than EE certificates).
>> >>
>> >> The reason this is problematic is that one can't really rely on clocks:
>> >> - Even if you happen to have sub-second accurate clock, a lot of
>> >> computers
>> >> don't.
>> >> - The time protocols often aren't secured, allowing attacker to play
>> >> tricks
>> >>   with endpoint time.
>> >
>> >
>> > We're already starting to have that problem because of a desire to move
>> > to
>> > OCSP
>> > stapling, which, with staple, effectively gives the server a credential
>> > which is
>> > valid only within a fairly narrow window. However, I think you're right
>> > that
>> > this
>> > probably limits the range of lifetimes you can use with these signed DH
>> > keys.
>> That's not the problem Illari was talking about: It's not that g^s has
>> limited lifetime, but that there is no way to know that the lifetime
>> is expired, so it has long lifetime. NTP is not secure, so we have to
>> deal with bad clocks. In the case of certificates, this is usually not
>> so bad as the lifetimes are long. It might not be a problem for this,
>> as we can occasionally resign, keep s in memory and not be worse off
>> than today, or say that TLS clients need trusted clocks to avoid
>> compromise when s is revealed.
> Yes. I understand this. My point is that OCSP Stapling is effectively
> like short-lived certificates (and short-lived DHE shares) in that
> you have a credential which is valid for a relatively short period of
> time and which therefore requires that therefore requires tight
> clock synchronization. And since we're moving towards OCSP
> stapling and short-lived certs, we've got this problem in any case.

Ah, I was thinking of a different problem with OCSP stapling, which is
getting the response to staple periodically, and when you don't...

Thinking about it more, I think I don't understand this. X509
certificates have expiration dates. Doesn't that mean the client needs
a synchronized clock already? Why does the duration of the validity of
the response affect the existence of this issue?

With OCSP stapling this problem gets worse because there is no
freshness: it's a stapled response, and one of the security goals was
making revocation take hold quickly So I think an attacker who can
play games with time can already break OCSP stapling. Here we're
limiting the validity time of something equivalent to a certificate,
to deal with all sorts of problems that could lead to disclosure of

But it seems like this mechanism might not work, because of endpoint
timing issues where the attacker gets to set the clock. How much worse
off are we than when certificate expiration times or OCSP validity
times get played with?

> Arguably, the situation is slightly better here because the server
> gets to select the key lifetime and so it can tune it depending on
> its assessment of client clock accuracy, which is unlikely to be
> the case with OCSP stapling.

The problem isn't that the client has an imprecise clock: +/- 10
minutes should not pose a problem. The problem is an that an attacker
can set the clock to whatever they want if they control the network.
Tuning the validity period doesn't change this. It's not an
operational issue, but a security issue.
> -Ekr

Watson Ladd