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

Nikos Mavrogiannopoulos <> Sat, 01 November 2014 09:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E099E1A6F3C for <>; Sat, 1 Nov 2014 02:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.211
X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jNjQbvMXzDpF for <>; Sat, 1 Nov 2014 02:41:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1385B1A6EE7 for <>; Sat, 1 Nov 2014 02:41:10 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id sA19f29B024838; Sat, 1 Nov 2014 05:41:03 -0400
Date: Sat, 01 Nov 2014 05:41:01 -0400
From: Nikos Mavrogiannopoulos <>
To: Hugo Krawczyk <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922)
Thread-Topic: OPTLS: Signature-less TLS 1.3
Thread-Index: xJgTdjMcmzr296usZXxmggcSP4UG7A==
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: Sat, 01 Nov 2014 09:41:13 -0000

----- Original Message -----
> 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.

That effectively deprecates all existing infrastructure used for TLS that pretty
much only works with RSA and ECDSA certificates (from smart cards, to HSMs and
acceleration hardware). That's not necessarily bad, and we may already be past the
point where TLS 1.3 can be considered a minor revision of TLS 1.2.

> 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.

How does the client get the DH (or ECDH) group parameters used by the server?

> 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}).

As I understand client authentication as above would only work if both the client
and the server share the same DH/ECDH group for their certificates, and that cannot
be assumed to be true on an infrastructure that is designed to upgrade (e.g., change
client certs from secp192r1 to secp256r1).