[TLS] OPTLS: Signature-less TLS 1.3

Hugo Krawczyk <hugo@ee.technion.ac.il> Sat, 01 November 2014 00:54 UTC

Return-Path: <hugokraw@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id EB7191A8763 for <tls@ietfa.amsl.com>; Fri, 31 Oct 2014 17:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.023
X-Spam-Level: **
X-Spam-Status: No, score=2.023 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9RYVKMdNCuwx for <tls@ietfa.amsl.com>; Fri, 31 Oct 2014 17:54:41 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD6F1A8760 for <tls@ietf.org>; Fri, 31 Oct 2014 17:54:40 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id q1so7095151lam.38 for <tls@ietf.org>; Fri, 31 Oct 2014 17:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=z1+iO5mPaPAhY0dSHG6L064XJu7zXTUQjG7EKw0hXb8=; b=K4u9UwKXnmlWmUrvkT5ZRE49vEIcxHtyssCce0s2EUlyn12oJFKYHJaJUVHOts7/0T eGY1/+Ey26CCPQ2BFv0dRDrmj2Wl61DsYVCVhVdT5YrJgryceQHMGZ7YO+imJ3nuqcos DnsNYrHz/ZzOl9H47prDk5jOB5p74ivxUOd0x1wIM4QxBgAY9vM/5t9B7GvM3CRwyjfo QEdqBj3pqoOytT+AYcUM3D+014I65owoqde6PoAZAqlL5tBtfTtCdpJP3TxC8w5rz4Lp YOxkk8rUZXY9dDe90TAolqbLOb5P3fEV/L84/jIv21Adnqrss6O5P+7gy5gY4nfqfU5l NUMw==
X-Received: by with SMTP id h10mr30102361lbz.33.1414803278824; Fri, 31 Oct 2014 17:54:38 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by with HTTP; Fri, 31 Oct 2014 17:54:08 -0700 (PDT)
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Sat, 01 Nov 2014 02:54:08 +0200
X-Google-Sender-Auth: HYkLVY5U2ry9Qc5RnOQUbgCf65A
Message-ID: <CADi0yUObKsTvF6bP=SxAwYA05odyWdzR1-sWutrDLUeu+VJ1KQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11347168dc8ddc0506c18ed0"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ma_T1AL5_jMarTB8Ci0vdfYCoVM
Cc: Hoeteck Wee <hoeteck@alum.mit.edu>
Subject: [TLS] OPTLS: Signature-less TLS 1.3
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Nov 2014 00:54:45 -0000

During the TLS interim meeting of last week (Oct 22 2014) I suggested that
1.3 should abandon signature-based authentication (other than for
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility
the mechanisms required for forward secrecy, natural accommodation of a
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
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
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
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
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
All the public key and Diffie-Hellman operations are assumed to happen over
cyclic group with generator g of order q (typically implemented by an
curve group). We use multiplicative notation where ^ denotes exponentiation
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
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic


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
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.


ClientData* [K0]       -------->
                                           ServerCertificate* [K1]
                                           ServerFinished [K2]
                       <--------           ServerData* [K2]
ClientFinished* [K2]   -------->

            Protected Application Data [K3]


The basic 1-RTT case omits the ClientData* field. It includes a
g^x and a ServerKeyShare g^y and an optional (encrypted) server
If the certificate is sent (it can be omitted if the client has indicated
it knows the server key as in the case in the 0-RTT scenario) and is
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
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server
such data is piggybacked to the second message.

Key K3 is the "application key" used to derive key material for protection
application data.  This key material will include (directional)
Encryption keys and, possibly, keys for derivation of further re-key
K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its
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
and other security parameters. The server is assumed to have some mechanism
place for detecting replay (e.g., via timestamps, stored client nonces,
The resulting protocol is as described above where the ClientData field is
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
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message
the application key K3 would be derived from a combination of the values
g^xs, g^yc (and possibly also g^{cs}).


Note on Finished messages: The above spec sets ServerFinished as mandatory
ClientFinished as optional. The latter option is needed for a 1-RTT
In principle, both Finished messages could be omitted and still obtain
via implicit authentication (assuming the inputs to key derivation are
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
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof
CK security implies UC security when a client confirmation step is

Note on certificates: Since in current practice servers hold certificates
RSA signature keys rather than for static DH keys, the certificate field in
above protocol will be implemented by a pair consisting of (i) the server's
signature certificate and (ii) the server's signature using this RSA key on
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
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
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,
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).