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

Hugo Krawczyk <> Tue, 24 March 2015 15:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 565CA1A893E for <>; Tue, 24 Mar 2015 08:40:45 -0700 (PDT)
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 dPsi2K0OJfIK for <>; Tue, 24 Mar 2015 08:40:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09FA11A896B for <>; Tue, 24 Mar 2015 08:40:29 -0700 (PDT)
Received: by lbbsy1 with SMTP id sy1so143915734lbb.1 for <>; Tue, 24 Mar 2015 08:40:27 -0700 (PDT)
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=XivLCES712tUiO3tQb7vJTE/Lmeyl3aR33LCZkUE0KU=; b=YhoFXO24I2Af6mtiWcT/eJB7+mqtuMtvjTdGlP1YYBmcVSf+0lDH8km5mNTunswliw LZP25Lk8uG+eMYnzvEuAk2XjD0107gIg/1cLuEpW/LFA8NoQ7SmydDIzWUSTkFGBnvEx Dq46qE437VFXR29nChgyEIXs13faoc7th2atWyMza1hTH3jfvhPnJQLXKrSBrjXOI2A4 MybhnUUP0MZlDVP2eFE4vJYJ7dE7T64V1g3EZEm270yX9/QOcirOk+xUfT3TsAFR61Zs +lDA+phCchCBhVvCPaHqTLszfWzYyb+quEV9WX3bnMekZ/wUZVk64H5SVc4TXzkUSeLj B1wA==
X-Received: by with SMTP id lm6mr4346448lac.35.1427211627460; Tue, 24 Mar 2015 08:40:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 24 Mar 2015 08:39:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Hugo Krawczyk <>
Date: Tue, 24 Mar 2015 11:39:57 -0400
X-Google-Sender-Auth: IwHVwMgd8159MpGdbrpQQ9LDCRw
Message-ID: <>
To: Rene Struik <>
Content-Type: multipart/alternative; boundary="001a1134a00a13006305120a9a33"
Archived-At: <>
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: Tue, 24 Mar 2015 15:40:45 -0000

I absolutely agree with you and I am not asking to take my word on the
cryptographic design. This all needs review. I am just saying that
reviewers will not have to cope with some hard-to-digest revolutionary
ideas. And, yes, we hope to improve on TLS mixed record...


On Tue, Mar 24, 2015 at 11:31 AM, Rene Struik <> wrote:

>  Great - looking forward to the technical write-up, when it becomes
> available.
> One quick question: if I remember correctly from your original OPTLS
> sketch, you paid some tribute to a "modus operandi" that includes client
> authentication as well (i.e., making this into a mutually authenticated key
> agreement scheme). I would be curious whether this is still on the table
> and, if so, whether this would also follow the same online signing approach
> you sketched below for the server. Apologies in case I missed some of this
> finer detail (hence, my interest in having a concise overall and
> technically complete description).
> While I do appreciate lots of this is "simply" cryptographic engineering,
> I do think you would have to agree that TLS has a mixed record here. Hence,
> some reflection and careful analysis seems to be in order, in addition to
> the great contributions you made yourself so far.
> Best regards, Rene
> On 3/24/2015 11:11 AM, Hugo Krawczyk wrote:
>  Hi Rene,
>  We are working on such a write up as  we speak. Exactly because the
> details matter and we have been changing them to adapt to the WG
> requirements and preferences then the writing has been delayed. We are now
> converging to a protocol that the people in the interim meeting were quite
> happy with. It is in the same spirit of OPTLS but it is not signature-less,
> i.e., semi-static keys for the servers are now signed with online
> signatures that prove freshness by including the client's nonce under the
> signature.
>  We should have something decent to post in two weeks.
>  But let me note that there is nothing revolutionary in the protocol - it
> is crypto engineering with well understood components, not inventing new
> fundamental pieces.
>  Hugo
> On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik <>
> wrote:
>>  Hi Hugo:
>> In your email of October 31, 2014 (see below), you introduced the OPTLS
>> protocol to TLS. At the time, you omitted some details, since you simply
>> wished to socialize the ideas. You did emphasize, though, that details
>> matter and put forward that you were working on flashing out the full
>> details of the protocol and security proof.
>> After a few months of radio silence (to me), the protocol seems to be on
>> the radar screen for discussion with TLS again. It would therefore be good
>> to have a stable reference that describes this in full technical detail and
>> makes this a stable and solid source for the cryptographic community to
>> look at and reference.
>> I do think that OPTLS has interesting features, perhaps also outside TLS,
>> but would like to give this a thorough and critical look first (and invite
>> others to do so as well). For this, it would help to have something beyond
>> some emails on the TLS list and some "flashed out" draft spec Eric Rescorla
>> worked on earlier this week (which, although useful, may change over
>> time).  Having a stable document would make this more appealing to study
>> and discuss in a wider audience, esp. for important potential use cases.
>> If you have a paper (e.g., one you could post on the IACR ePrint server),
>> that would be great. {Rest assured, this does not have to have the same
>> size as your 2005 paper on HMQV for it to be useful.}
>> Best regards, Rene
>> ==
>> "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."
>>   On 10/31/2014 8:54 PM, Hugo Krawczyk wrote:
>>  During the TLS interim meeting of last week (Oct 22 2014) I suggested
>> that TLS
>> 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]
>>                        <------->
>> 1-RTT CASE:
>> 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).
>> _______________________________________________
>> TLS mailing listTLS@ietf.org
>>   --
>> email: | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
> --
> email: | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363