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

Hugo Krawczyk <> Wed, 05 November 2014 16:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A107B1A899D for <>; Wed, 5 Nov 2014 08:28:27 -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 76Mqrlv9c_bh for <>; Wed, 5 Nov 2014 08:28:25 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B3BF1A037F for <>; Wed, 5 Nov 2014 08:28:24 -0800 (PST)
Received: by with SMTP id ge10so979463lab.22 for <>; Wed, 05 Nov 2014 08:28:22 -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=d0EmQgqV1U6IOjivPh4pkkNZ6J8RWhtJDsZD9/Kg0Zk=; b=Guf6QhMZWfm2wHXJf3ZB4fyizaJ1p3sIU5dUiLrQ/jF04P4YsFiW/qTJHhi/lJoSSm yLL1OasnhYRZeOcMb7kN1X/5TAgtnbn0qFgcE0XTKnly69WOxjCgf3XiAtOaLxsAKrwM inKB8eoyf5M39Koul2eDeDeuaUe1gjnYrYcx02JfHUsiVqFOOsztpPSlUbCZrfN4d7ms 2BmAxapNhXaUlYLy3gMT1oBTl8oRVbu2cmM58k1PV666wZdyr7IT46CbbcvALuVLRAiS 2nM1x+Jbo9MF4klS/Kw2kbA2Qy7xpcLbWqfEAkh015pPeRQCtPri1KDxR4+4g6mGWz9d bisQ==
X-Received: by with SMTP id x9mr21726570lax.95.1415204902677; Wed, 05 Nov 2014 08:28:22 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 5 Nov 2014 08:27:52 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Hugo Krawczyk <>
Date: Wed, 05 Nov 2014 18:27:52 +0200
X-Google-Sender-Auth: B1GFEuzxBvQzyyUmXU0HTZ5GBFs
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="089e0141a9a282326e05071f117f"
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: Wed, 05 Nov 2014 16:28:27 -0000

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?


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