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

Hugo Krawczyk <> Thu, 06 November 2014 09:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E9D431A1AB0 for <>; Thu, 6 Nov 2014 01:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CtvJPm46KJCm for <>; Thu, 6 Nov 2014 01:35:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0A161A1AAB for <>; Thu, 6 Nov 2014 01:35:05 -0800 (PST)
Received: by with SMTP id hz20so2216937lab.23 for <>; Thu, 06 Nov 2014 01:35:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xTQewjHVwk+znV5ymGLOeVYkAOZ0apyFTjRWWkOnZ+8=; b=ntJ28szDbofRT/VhKCWm/rc+ttOgZYn0l6+F5bLtazVSt0jrht5SdsKdubh8PTRAkF YuiTm17dETz58NkuM/S3xCyQwvxBR077CKk8fs4lwF7X1SngdUaFS/LmngDpnRHJjRyu 4h9gqqpKESz4gggduow45CnGUYDJh8BRE0koq8Ve/KwRv+KDuVU3Du9Au9qF7hblaK7V 0nTjhIQ7wc1noQAt6/UMN/rAxYYLZkFdnSQc6/RRi5MiDUzWDjxhPqGKWITbruhpzKVS cZVVfCDq+hkEx+jEJxBzQcv52hWlIsJzooPzLUEUJTDYk46i0UngU9XwKNbQUO7n2wxV wS3g==
X-Received: by with SMTP id yb11mr3694851lbc.51.1415266504219; Thu, 06 Nov 2014 01:35:04 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 6 Nov 2014 01:34:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Hugo Krawczyk <>
Date: Thu, 06 Nov 2014 11:34:34 +0200
X-Google-Sender-Auth: gOD05YBX1JlDFKgShQMR6_TqfL8
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="001a1134de923f505c05072d69f6"
Cc: "" <>
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: Thu, 06 Nov 2014 09:35:10 -0000

I agree that when a signature key is better protected than the static DH
key, requiring a fresh signature in each session is better. I assume that
there is no fundamental reason not to have the static DH key in the HSM
other than the fact that this capability is not supported in current HSMs.
We are in a transition period and there are some costs associated to it,
but we should not tie ourselves to the past for this reason. This is a
forward-looking proposal. Besides, it also has advantages regarding the
security of long-term signature keys which need not be online for signing
each exchange.

Regarding the problems with insecure time, it seems that we are reaching
agreement that this should not be a distraction for judging this proposal
(in particular since it does not make things worse than the reliance of
time synchronization for accepting certificates - and it can actually make
things better by having shorter validity periods for the static DH key than
for the long-term certificate).

BTW, I have not mentioned one advantage of removing online signatures from
​ the protocol: It provides plausible deniability of an exchange. In
contrast, with per-exchange signatures that sign all the handshake
messages, you also sign your peer's identity, hence leaving a proof that
you communicated with that peer. The deniability property of OPTLS can be
claimed similarly to that of SKEME as in
This is an additional privacy-protecting aspect of the protocol in addition
to identity encryption and forward secrecy.


On Thu, Nov 6, 2014 at 8:54 AM, Eric Rescorla <> wrote:

> On Wed, Nov 5, 2014 at 8:27 AM, Hugo Krawczyk <>
> wrote:
>> The issue of validity period of the static key g^s is not different than
>> that of a regular certificate except that the server can choose a shorter
>> validity period for g^s than the one for the certificate. That is, if the
>> client's clock is skewed by Delta and the validity of g^s is up to time T,
>> the client will accept g^s till time T+Delta. Similarly, if the certificate
>> expires at time T', the client will accept it until T'+Delta. In either
>> case, if T<T' the client will accept g^s for less time than it would accept
>> the certificate.
>> (Needless to say, a client should not accept a signed g^s past the
>> expiration date of the certificate signing g^s).
>> Am I misunderstanding/missing something?
> I'm not sure.
> The point I was trying to make below is that there are settings in which
> the
> signing key is stored in an HSM but the DH share cannot. In those cases,
> there is an additional risk of compromise of the machine holding the DH
> share, which can steal the share but cannot steal the signing key
> (because of the HSM). I agree that this is partially ameliorated by
> having g^s be only valid up to the expiry of the certificate, but since
> certificate lifetimes are generally long, only partially so, especially
> since
> if the signing key is online (as will be required for TLS 1.2 compat)
> compromise of the machine will let you sign a DH share with a very
> long lifetime.
> is that clearer?
> -Ekr
>> Hugo
>> On Tue, Nov 4, 2014 at 4:12 PM, Eric Rescorla <> wrote:
>>> On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd <>
>>> wrote:
>>>> On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla <> wrote:
>>>> > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <>>
>>>> The second option may be trivial, if the client already has some
>>>> > generic key storage mechanism (e.g., one in software) though it's of
>>>> > course more work for the programmer. However, if the client has a
>>>> > non-generic key storage mechanism, such as a smart card with their
>>>> > key, then this becomes a significant problem, as it may not be able to
>>>> > store a DH key and/or use it for the kind of key derivation that
>>>> > would be required here. In that case, the client must find somewhere
>>>> > to store the DH key, which may entail significant effort.
>>>> >
>>>> >
>>>> > This last point points us to a larger issue we need to consider here,
>>>> > which is as follows. In TLS as it currently stands (both in 1.2 and
>>>> > the current TLS 1.3 draft), you can implement a system where the
>>>> > authentication keys are stored in hardware and an attacker who
>>>> > compromises either the client and the server cannot steal a credential
>>>> > which he can then use to establish new sessions [Note that if
>>>> > he steals the session cache, he can use it to resume old sessions.]
>>>> > In particular, because each signature is tied to a specific exchange,
>>>> > the attacker cannot reuse signed ephemeral values to impersonate the
>>>> > server.
>>>> 1: If ephemerals are reused, you can MITM until they are refreshed. A
>>>> time-bounded cert equivalent isn't worse in this regard.
>>> I'm not following your reasoning here. For convenience, let's
>>> restrict ourselves to thinking about 1-RTT handshakes. With
>>> TLS 1.2 (or the current TLS 1.3 draft), the server can stop future
>>> clients
>>> from accepting any DH share simply by refusing to sign any
>>> further handshakes with that share. If, for instance, it determines
>>> a share has been compromised, it can prevent any new connection
>>> initiations with that share. By contrast, with a time-bounded
>>> cert, an attacker can get clients to continue using that share until
>>> the time expires (or perhaps longer, as you suggested elsewhere).
>>> The situation is of course somewhat more complicated with 0-RTT
>>> because the server must provide the client with a DH share which
>>> he can use for future connections. However, he need not provide
>>> every client with the *same* key, and if the key is authenticated
>>> as part of the initial connection establishment, an attacker cannot
>>> convince other clients to use that key. This is not true with
>>> certificates
>>> (or of statically signed keys) which are inherently portable.
>>> 3: 0-RTT requires a certificate that can be used for encryption as
>>>> well as signing, in ways that don't interfere. We need to use a DH
>>>> share anyway for this, and might as well use it again.
>>> I'm not sure I follow what you're saying here either. It's true that the
>>> server needs to supply a semi-static DH share, but there's no inherent
>>> reason it needs to be supplied as part of a free-standing transferrable
>>> credential such as a certificate, though of course doing so allows you
>>> to amortize the signature.
>>> > However, in a system where the server signs a long-term DH value, it
>>>> > may be the case that that value cannot be stored in the same hardware
>>>> > module that you are using for your signature key (purely for
>>>> > implementation reasons having to do with the interface the module
>>>> > exposes). In that case, the DH secret will be stored in software and
>>>> > compromise of the server potentially leaks a credential which can be
>>>> > used to impersonate the server for a significant period of time, where
>>>> > that time is dictated by the maximum amount of client-side clock error
>>>> > the server is willing to tolerate, so probably measured in days to
>>>> > weeks (and more if you are concerned about the time resetting attack
>>>> > Watson, Ilari, and I were discussing.) I haven't decided yet sure how
>>>> > serious an issue this is, but it's probably worth addressing
>>>> > explicitly.
>>>> I'm not sure, because it wasn't explicitly addressed in Hugo's
>>>> original email, but it seems that the relevant server question is how
>>>> long it wants to receive 0-RTT without requiring the client to find
>>>> the new address: I don't remember resumption being addressed one way
>>>> or the other. So the server isn't picking the DH share lifetime for
>>>> reasons of clock skew, but rather for PFS refreshment if 0-RTT is
>>>> being used.
>>> I think we may be talking past each other. Let me try again.
>>> Forget about 0-RTT and just consider the 1-RTT flow. In the first flight
>>> the server needs to supply a signed version of g^s. Unless we want
>>> that value to be acceptable to clients indefinitely, it must have some
>>> validity interval. However, because clients have inaccurate clocks,
>>> that interval can't be too narrow or it will cause clients to reject the
>>> g^s value. I'm not sure how narrow it can be, but I would be surprised
>>> if it were less than 12 hours or so. Perhaps someone who runs a
>>> large server farm can report on the values they have historically
>>> seen in the GMT field of the ClientRandom.
>>> -Ekr