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

Hugo Krawczyk <> Thu, 13 November 2014 04:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 33DB81A1B4D for <>; Wed, 12 Nov 2014 20:03:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t5yS_7A6ddDV for <>; Wed, 12 Nov 2014 20:02:57 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 079341A1B49 for <>; Wed, 12 Nov 2014 20:02:57 -0800 (PST)
Received: by with SMTP id b6so10387712lbj.2 for <>; Wed, 12 Nov 2014 20:02:55 -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=fIw3rWd3TSNfVmSQM+zvP0n+q1L6R9SaiUw9rUQOrCo=; b=uBrElkZFQjab4VXdhAKrUm2UM6WP7hL6P1fYI528inFGCD3AdT7xj5F4tTWA9KVIFZ gmRWzfqbri4PvPv/Icpwes3CRcvTbYH10YXkbk1J7qw/H5KPGWTaQIqQbEv0pokZE6ms RhrQZGhhVnwy+ClJEx0VUMv8WxTtFI2ak9NN9WkI/GJ6WYnOQ08To8vA6j4iBrAWWz3u y3MVVtu1s/CD2WbmVGY7KI7QaMCcLhEIjgSRP+KwSC4arDZqX6g5slR0Qia6+BzfZ68W bMfp+zdEFotOwJ/Zsl/G7rGBlmZkOkuik+uonE3wHewT93DNgfxCl3UWjRz7klgaixAz bwVw==
X-Received: by with SMTP id jj4mr25592238lbc.71.1415851375341; Wed, 12 Nov 2014 20:02:55 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 12 Nov 2014 20:02:25 -0800 (PST)
In-Reply-To: <20141111203740.GN3412@localhost>
References: <> <> <> <20141111005220.GG3412@localhost> <> <20141111021201.GH3412@localhost> <> <> <20141111173325.GK3412@localhost> <> <20141111203740.GN3412@localhost>
From: Hugo Krawczyk <>
Date: Wed, 12 Nov 2014 23:02:25 -0500
X-Google-Sender-Auth: FoZo9tDg7s-nlY4O1le-ph1oasw
Message-ID: <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="001a11c2a9964836c40507b596bb"
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: Thu, 13 Nov 2014 04:03:00 -0000

>From the discussions in this list and some offline conversations it is clear
that people like OPTLS for its features but are concerned with the issue of
"delegation", namely, the need for the server to create certificates for
static DH keys g^s by signing (using the RSA key in the server's
the key g^s, the validity period (T1,T2) and possibly some other
I'll call this signature a sub-certificate or subcert (some suggested
this a proxy certificate but I prefer not to use established terminology
I am not sure what the exact semantics/connotations of these terms).

Here is a summary of the concerns and some of the available techniques to
with them.

* The delegation concerns do NOT exist in a model where the attacker either
  gets full control of the private signing key (e.g., steals it) or
  has no access to it. Indeed, in this case either the  key is secure and
  attacker cannot produce subcerts or the key is fully compromised and one
  cannot possibly provide server security (in this or any previous version

* Thus, delegation concerns only arise when assuming an attacker that cannot
  steal the signing key but can get temporary access to a signing device and
  create a few signatures on arbitrary data. In such case, the attacker can
  generate subcerts for keys g^s for which it knows the secret key s, hence
  allowing him to impersonate the server against any client accepting this

* I am not sure how common the above "partial exposure" problem is in
  but note that if the signing key was only used to generate TLS 1.3
  then it could be well guarded since it would be used rarely and never
  online. This would be the case if servers equipped themselves with
  certificates solely used for this purpose (rather than using the same
  certificate in protocols like TLS 1.2 that require online signatures).

NOTE: One way of using a TLS 1.3 RSA key would be to generate a bunch of
subcerts for g^s values in all the EC groups that the server supports and
DESTROY the signing key. (This is equivalent, functionally and
to getting DH certificates for all these groups without requiring the CA to
issue DH certificates at all!)

* Assuming that servers will not want to get certificates for use with TLS
  only (why not?), then we need to address the above subcert forgery
  where the atacker gets limited access to the signing key. An imperfect but
  effective solution is to only issue subcerts with short validity period,
  i.e.  where the difference T2-T1 is small. In this case the attacker with
  temporary access to the signing key can only create a limited number of
  subcerts covering a limited time span.

Operational note: It is the servers' responsibility to create such
subcerts but it is the clients' responsibility to check the subcerts are
indeed short-lived (otherwise an attacker can generate a long-lived subcert
that the client will accept).

* Clients with clocks with significant deviations from the correct time will
  have trouble accepting valid subcerts and may be induced to accept old (or
  into-the-future) subcerts. I can imagine this to be a problem. But is it
  enough to abandon the benefits of a ECDH-based solution like OPTLS?

* The acceptable validity periods can be fixed by the protocol or can be
  of the "negotiation" where the client will say which validity-period
  are acceptable to him and the server will send an error message if it does
  not support such periods. Or the server can simply send the subcert with
  shortest validity period which is still valid and the client accept it
  depending on his clock and policy.

Note: One could accommodate, in principle, a period length of 0, meaning a
subcert that is only valid instantaneously; in other words, this would be a
per-session signature on g^s that will also include the client nonce.

* There is no need to have a revocation mechanism for subcerts. The rule is
  that subcerts are not accepted once the RSA certificate is expired or
  revoked. Hence, the revocation of the RSA certificate implies revocation
  all subcerts signed with it.

FINAL NOTE: The above issues will be eventually solved with servers getting
certificates for use with TLS 1.3 (either ECDH certificates or signature
certificates used as explained in the first NOTE above).


On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams <>

> On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote:
> > > On Nov 11, 2014, at 7:33 AM, Nico Williams <>
> wrote:
> > > That the "sub-cert" needs either a revocation scheme (not likely) or a
> > > short lifetime.  The latter puts this on a par with session resumption,
> > > thus making one (well, me) wonder what the advantage to the static DH
> > > concept would be.
> >
> > There is a revocation scheme. If the private ECDH key is lost, you
> > revoke the certificate, thereby invalidating the delegation.
> Ah, good point!
> > > We could put static DH keys in DNSSEC and learn them that way, which
> > > would get us 0rt.
> >
> > Another possibility is to place the ECDH public key in a certificate
> > extension. This gives it a lifetime as long as the certificate, and it
> > doesn’t matter whether the “regular” certificate public key is RSA or
> > ECDSA or anything else.
> Sure, certs could have multiple subject public keys.  That'd be a very
> nice.  A cert could have an encryption key, a different signature key,
> and a key agreement key.
> > It removes the need to use signatures at all by the server. Not even
> > once.
> Yes.  I like this.
> Nico
> --