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

Hugo Krawczyk <> Tue, 18 November 2014 20:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C27AD1A87AF for <>; Tue, 18 Nov 2014 12:10:48 -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_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id izhgM66wGyEd for <>; Tue, 18 Nov 2014 12:10:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB9AD1A87A4 for <>; Tue, 18 Nov 2014 12:10:35 -0800 (PST)
Received: by with SMTP id l4so18266426lbv.10 for <>; Tue, 18 Nov 2014 12:10:34 -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=4V64fVAKipnMdFjirM35ixQ5dFJ2HAd94DRjk9H828g=; b=jcTO2FuYz56U0HbmKBAw+m1gQ20c3SJxJsYkQtTk7DxM7pOAts2jKwi/WOcEnkN02O v3jd7rIydJdwNQjLEeHbfcyR3tpINpzXb1c8KQhS2F+ecV7527SgwiFcQT+3UlAGYJns Rqx/a8GSzQ2TcSEt70nMg7PXE0OjC2Y91sTSt0J8a8FdpA2D4PhwQZ1yHmD9hIWiAptR jfmTkCIhjN4oPGbS23zGeuAnWK9JEJeXvW0MF29llca+jQ5Va3mebqCPsdWiSJauc3rz rKEa50rgtkCjyOMmXtiqvCq3ze+gFBtdq/IpNHgUuxAxCMpfmxNyJruWGJwqEDq8IrHG jKSw==
X-Received: by with SMTP id jy8mr1137380lbc.65.1416341434216; Tue, 18 Nov 2014 12:10:34 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Nov 2014 12:10:04 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Hugo Krawczyk <>
Date: Tue, 18 Nov 2014 15:10:04 -0500
X-Google-Sender-Auth: k9CQXmfmfvGiqrbue-uUlkWqfdo
Message-ID: <>
To: Dan Brown <>
Content-Type: multipart/alternative; boundary="001a11c372da1137ac050827b031"
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: Tue, 18 Nov 2014 20:10:49 -0000

I am aware of these protocols of course (and their shortcomings) and of
several other relevant works (e.g Katz et al).
There is also my own SKEME protocol from 1995 (which predates these other
schemes) which is closer in the approach to OPTLS in the sense of providing
a flexible framework for supporting things like session resumption and
Pre-shared key.
None of these, however, support basic requirements from OPTLS such as 0-RTT
and server-only authentication.

In any case, similarity between KE protocols is not a guarantee of
security. The devil is in the details, and OPTLS has not even fixed these
details. We are waiting to understand better the requirements before fixing
these. It may well be the case that there will be no need to fix them if
the WG is not interested in pursuing this direction (which is quite a


PS: BTW, the UM protocol from NIST 56A is not only subject to UKS but also
to the interleaving attack from BJM.

On Tue, Nov 18, 2014 at 11:53 AM, Dan Brown <> wrote:

> Some similarity between the OPTLS proposal and some previous key
> agreements schemes may be relevant.  The main benefit of such similarity is
> that portions of the previous security analysis (whether security proofs,
> or lack of attacks) of the previous schemes may be applicable to OPTLS.  In
> other words, OPTLS is not a radically new design. Obviously, the details by
> which OPTLS differs from previous schemes can be also be very important,
> especially with different goals and fixes to defects.
> One previous similar scheme is Blake-Wilson, Johnson and Menezes (BJM) key
> agreement (protocol 1). Specifically, if one replaces the initiator
> (client) static key with the ephemeral key in the BJM protocol, then BJM
> derives an authentication key in a way similar to OPTLS, and derives a
> separate session key from both ephemerals, similar to OPTLS.
> Another previous similar scheme is the unified model key agreement from
> NIST SP 800-56A (and ANSI X9.63).  As with BJM, OPTLS differs from Unified
> in that OPTS replaces a static key from one side (the client) with the
> ephemeral key, and derives several types of keys (instead of just one in
> Unified model).  The unified model key agreement has the defect of
> key-compromise impersonation (KCI attacks), but that does not seem to apply
> to OPTLS if the client is anonymous.
> Best regards,
> Dan
> *From:* TLS [] *On Behalf Of *Hugo Krawczyk
> *Sent:* Friday, October 31, 2014 8:54 PM
> *To:*
> *Cc:* Hoeteck Wee
> *Subject:* [TLS] OPTLS: Signature-less TLS 1.3
> During the TLS interim meeting of last week (Oct 22 2014) I suggested that
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for PFS
> and
> static Diffie-Hellman for authentication. This has multiple benefits
> including
> major performance gain (by replacing the per-handshake RSA signature by the
> server with a much cheaper elliptic curve exponentiation), compatibility
> with
> the mechanisms required for forward secrecy, natural accommodation of a
> 0-RTT
> option, and a simple extension without signatures for client
> authentication.
> Below I present a schematic representation of the proposed protocol
> referred
> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
> The presentation is sketchy and omits the exact procedure for key
> derivation.
> The latter is a crucial component for the security of the protocol, but
> before getting into these details we want to get a sense of whether the WG
> is
> interested in this approach. In the meantime, Hoeteck Wee and myself are
> working on the details of the protocol and the security proof.
> We describe a setting with optional 0-RTT and server-only authentication.
> Client authentication can be added as a further option or as an extension
> (similar to the current 1.3 proposal) - see below.
> [K] symbols represent pointers to key material whose exact derivation is
> not
> included here except for specifying the basic DH values from which the key
> is
> derived (actual derivation will include further information similar to the
> extended hash mechanisms or SessionHash proposal considered for 1.3).
> Asterisks represent optional fields that the WG can decide to leave as
> optional,
> mandatory, or simply remove without changing the core cryptographic
> security of
> the protocol. All references to encryption mean "authenticated encryption"
> using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).
> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the
> parties.
> All the public key and Diffie-Hellman operations are assumed to happen
> over a
> cyclic group with generator g of order q (typically implemented by an
> elliptic
> curve group). We use multiplicative notation where ^ denotes
> exponentiation as
> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y),
> etc.
> Omitted from the current high level description is a mechanism for testing
> group
> membership of DH values or cofactor exponentiation (the specific mechanism
> depends on the group type and is typically very efficient for elliptic
> curves).
> The server has a long term private-public key pair denoted by (s,g^s)
> where
> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
> We assume that the server has a certificate that includes the server's
> public
> key g^s and a CA-signed binding of this key to the server's identity.
> We discuss the implementation of such certificates below.
> ClientHello
> ClientKeyShare
> ClientData* [K0]       -------->
>                                            ServerHello
>                                            ServerKeyShare
>                                            ServerCertificate* [K1]
>                                            ServerFinished [K2]
>                        <--------           ServerData* [K2]
> ClientFinished* [K2]   -------->
>             Protected Application Data [K3]
>                        <------->
> The basic 1-RTT case omits the ClientData* field. It includes a
> ClientKeyShare
> g^x and a ServerKeyShare g^y and an optional (encrypted) server
> certificate.
> If the certificate is sent (it can be omitted if the client has indicated
> that
> it knows the server key as in the case in the 0-RTT scenario) and is
> encrypted,
> the encryption key K1 is derived from g^{xy}.
> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is
> used to
> authenticate-encrypt the ServerFinished and ClientFinished messages (which
> include a hash of the previous traffic) and to encrypt data from the
> server if
> such data is piggybacked to the second message.
> Key K3 is the "application key" used to derive key material for protection
> of
> application data.  This key material will include (directional)
> Authenticated
> Encryption keys and, possibly, keys for derivation of further re-key
> material.
> K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its
> derivation
> will be different than K2, e.g., using a separating key expansion
> technique.
> The above protocol is compatible with a 0-RTT protocol such as QUIC. In
> this
> case, the client is assumed to have information about the server's public
> key
> and other security parameters. The server is assumed to have some
> mechanism in
> place for detecting replay (e.g., via timestamps, stored client nonces,
> etc.).
> The resulting protocol is as described above where the ClientData field is
> sent
> encrypted under key K0 derived from g^{xs}.
> The rest of the protocol is identical to the above.
> Note: In this case, ServerCertificate is not sent as the client had to know
> the server's public key before the first message (one can imagine a setting
> where the server may send a different certificate in the second message -
> if
> desired, this can be accommodated too as an option or extension).
> Client authentication can be supported via an option or extension. It would
> include a client certificate for a static DH key g^c sent in the third
> message
> (the certificate can be encrypted under key K2 to provide client's identity
> protection). In this case, the key for computing the ClientFinished
> message and
> the application key K3 would be derived from a combination of the values
> g^xy,
> g^xs, g^yc (and possibly also g^{cs}).
> Note on Finished messages: The above spec sets ServerFinished as mandatory
> and
> ClientFinished as optional. The latter option is needed for a 1-RTT
> protocol.
> In principle, both Finished messages could be omitted and still obtain
> security
> via implicit authentication (assuming the inputs to key derivation are
> chosen
> appropriately). But given the advantages of ServerFinished for providing
> explicit authentication, key confirmation, and active forward secrecy (see
> below), it seems advisable to always include it. Including ClientFinished
> provides key confirmation from client and also explicit client
> authentication
> when client certificate is included. ClientFinished also provides Universal
> Composable (UC) security (this is a result of the Canetti-Krawczyk proof
> that
> CK security implies UC security when a client confirmation step is
> included).
> Note on certificates: Since in current practice servers hold certificates
> for
> RSA signature keys rather than for static DH keys, the certificate field
> in the
> above protocol will be implemented by a pair consisting of (i) the
> server's RSA
> signature certificate and (ii) the server's signature using this RSA key
> on the
> server's static public DH key g^s. The latter signature by the server is
> performed only when a new static DH key is created (how often this happens
> and
> how many such keys are created is completely up to the server - it has the
> advantage that these keys can be changed often to increase security against
> leaked keys). This use of RSA also enjoys the high efficiency of RSA
> verification for the client.
> The handling of Client certificates would be similar.
> Note on forward security (a.k.a. as PFS for Perfect Forward Security):
> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
> The meaning of PFS is that an attacker that finds the (long-term) static
> private keys of the parties cannot compromise past session keys. Without
> the
> ServerFinished message the above protocol ensures forward secrecy against
> passive attackers (i.e., for sessions where the attacker did not choose
> g^y).
> With ServerFinished, PFS holds also against active attackers.  A similar
> consideration applies to ClientFinished.
> Client certificates in the first message: We note that in cases where
> client
> certificates can be sent in the clear in the first message of the
> protocol, one
> can provide PFS and mutual authentication in a 1-RTT at essentially the
> same
> cost of an unauthenticated DH exchange (i.e., a cost of little more than
> two
> exponentiations). In such a setting one can also obtain mutual
> authentication in
> a 0-RTT protocol (with forward secrecy with respect to the client's key).
> These options, however, require HMQV-like mechanisms and may raise IP
> issues (this
> can be investigated further if the WG is interested).