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

Eric Rescorla <> Sun, 02 November 2014 22:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D9CC1A1A3F for <>; Sun, 2 Nov 2014 14:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uAHqwwsk_LHQ for <>; Sun, 2 Nov 2014 14:34:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64AD31A0687 for <>; Sun, 2 Nov 2014 14:34:17 -0800 (PST)
Received: by with SMTP id x13so9885854wgg.19 for <>; Sun, 02 Nov 2014 14:34:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=csj2apvuKM9qli+4AJZnCvGk94lfQvqGfBYotWXYTnE=; b=LWqBk9ZkW4wDhncQ/Vwwz8r6JuxIz+dv7awynmpV4E0iE6Hl4CVWMioQAEOsekm6Lp fLd5BUGA2A97ZanuhXOlb3PXees3ydkfN2IntV028AzM4TtTQiRCxyN4xjOP5oqN7nK2 7aVGEENe8Yb0aibsIfqu0Ki1qE083ti9t8cdIE8RR0ppGfyR50cKiSIY4lu4dcAJMafW NrxB6JpcatAKTFzNwhzX7GGmUVGN3KIRlNUCmHhMHR2qjExQQFjXihpGAhLlsTEGYUz0 iotAvM4DQk0xGvnYVi648KLBTHDSlRml6WZtkJG5OmuX8Xf2XtJazIiDlJqiPDE/jf/t CQcw==
X-Gm-Message-State: ALoCoQl0yb10iIpDnAeHdAXgPN51BA55xD9lB4/kyDQJD5sFbuEln3oMsGAFWnYq0L+379cg0G7t
X-Received: by with SMTP id hh11mr11828654wib.80.1414967655989; Sun, 02 Nov 2014 14:34:15 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 2 Nov 2014 14:33:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Eric Rescorla <>
Date: Sun, 02 Nov 2014 14:33:34 -0800
Message-ID: <>
To: Hugo Krawczyk <>
Content-Type: multipart/alternative; boundary="089e0122950a8117580506e7d47a"
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: Sun, 02 Nov 2014 22:34:19 -0000

On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <>
> These are good questions as they point to some of the choices we need to
> consider before defining the actual key derivation mechanisms in the
> Below are some responses.

Thanks for your explanations.

> On Sat, Nov 1, 2014 at 3:44 AM, Eric Rescorla <> wrote:
> >
> > 3. WRT client auth, I think we've generally decided that the client's
> > certificate ought to be encrypted. Given that, I wonder if it would be
> > for the client to just do a digital signature over the transcript and/or
> > an authenticator derived from the secret. Generally, the additional
> > cost of the RSA signature isn't a huge problem for most clients and
> > those which do should be able to quickly move to EC-based keys.
> ​I don't see the advantage of signatures in this case. It is possible to
design a
> hybrid protocol with signature authentication at the client side and
static DH
> at the server but I wouldn't do that without a clear advantage over the
> uniform approach using static DH on both sides. In any case, doing static
DH at
> the client should not be a problem, it is already doing it to
authenticate the
> server and compute keys.

Thinking this through some more, if the client is doing certificate
authentication, it is already provisioned with a long-term signature
key and the corresponding certificate.  In order to do static DH for
authentication, it must either:

- Generate a new "static" DH key on the fly and sign it.
- Have some long-term storage where it stuffs the static DH key and
  its signature.

The first option is obviously more computationally expensive than not
doing so (though as I said above, not dramatically so if you are doing
EC). As you suggest, this isn't an issue for servers since they are
doing a lot of handshakes and can amortize the computation. However,
because the client may be slow but not do a lot of exchanges, it may
be an issue for clients.

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

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