[TLS] Re-thinking OPTLS

Hugo Krawczyk <hugo@ee.technion.ac.il> Fri, 21 November 2014 21:56 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 2565E1A8991 for <tls@ietfa.amsl.com>; Fri, 21 Nov 2014 13:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UP52Pb2OLxjg for <tls@ietfa.amsl.com>; Fri, 21 Nov 2014 13:56:03 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322E71A8A82 for <tls@ietf.org>; Fri, 21 Nov 2014 13:56:03 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id gq15so5078314lab.18 for <tls@ietf.org>; Fri, 21 Nov 2014 13:56:01 -0800 (PST)
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=ECAsyAxSiLEIukyE5wxCBsYjbMntFMT6m4J5u0synAw=; b=xqW9hViglVEeO9OS8JqIjiylzHuFdfLvGont/l88peEIp+ySdTVLv6+23iZdacyhh9 B8RypsN4QgwlLRErRq2VptTpiTN9Lemm/D94xc8ocfkH4a4oxFv0HkA1nduFgnN/K1IW IdjRNb8HkQ5nzmkdnY+vJn8RM8/RY4xj6f6gj70lFoW9YpI8kQML/pjnAjV5UWwPwf3e WcR41jrevgcwaXcZPl/pJnb5/GQQzwceWv/Dz4GoczNHvK75l4/y58Q75ZsiBYt1IIq3 a4SWHLg8tpUTNVpEa9IkA6gQrLSGauUs4lMzNnRHel0EuuhEHBPfZdOBYnNtgp6qyc5U GmYA==
X-Received: by with SMTP id yb11mr7717631lbc.51.1416606961531; Fri, 21 Nov 2014 13:56:01 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by with HTTP; Fri, 21 Nov 2014 13:55:31 -0800 (PST)
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Fri, 21 Nov 2014 16:55:31 -0500
X-Google-Sender-Auth: SBNrAziVORWP9pqhQM1q34lNKzc
Message-ID: <CADi0yUMCGuYbqrJWa-KXNmgNvc19xOWwpx2DCLOvgv62haedCQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1134de92ba82260508658213"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5Fz2nF2vcxJdiNJd-JwD64C_ze8
Cc: Hoeteck Wee <hoeteck@alum.mit.edu>
Subject: [TLS] Re-thinking OPTLS
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: Fri, 21 Nov 2014 21:56:08 -0000

>From information I received regarding the meeting in Honolulu (which I did
attend and whose minutes are still unpublished) I gather that there was not
enough support to continue consideration of the OPTLS proposal. This lack of
support was based on three objections:

- It is a "last minute" proposal that will delay the publication of TLS 1.3.

- The "delegation" issue: An attacker that can gain access to the server's
  signing box, without necessarily learning the signing key, can obtain a
  signature on a static DH key and use it to impersonate the server.

- The performance advantage of OPTLS relative to RSA signing is diminished
  when comparing to (current) TLS 1.3 with ECDSA signatures.

I think these are important points but I feel that they were not given
consideration, in particular, since there was not enough time to digest the
proposal before the Honolulu meeting. I believe that OPTLS offers
security and functional advantages over the current TLS 1.3 proposal and
should not be dismissed without a more focused discussion.  This is
particularly so if we can clear the issue of delegation that was the main
trigger to the change of sentiment on OPTLS from positive to "hesitating".

In this note, I will address the three issues. The arguments are incomplete
the interest of not making this long email even longer. I will be happy to
hear your feedback and expand on any issues that need further

*** The "last minute" objection ***

This proposal is indeed coming at a late point in the process of specifying
TLS 1.3. However, we are planning for a protocol that we hope will serve us
for many years; a possible delay of a few weeks should not be a determining
consideration. We must approach the design of TLS 1.3 with a
approach that considers evolving crypto technology, addresses a set of core
requirements and leaves some flexibility for future functionality.
TLS history shows that the protocol should be based on sound cryptographic
design requiring as little crypto machinery as possible, and providing a
consistent logic for the different modes of the protocol. OPTLS is rooted in
this approach, building fully on a single underlying mechanism -
Diffie-Hellman for both forward secrecy and authentication - and extending
naturally to other authentication settings such as 0-RTT, pre-shared key and
session resumption. Many of the benefits of OPTLS have been discussed in the
original thread in this list and will not be reiterated here in detail.
Please refer to these messages for more background:


*** The delegation issue ***

I would now like to address the very valid concerns with using the server's
existing signature key to sign static DH keys (a signature I refer to as a
"subcert"). This has been the only technical objection to the protocol
in this list and therefore I see its resolution as a necessary (and
sufficient) condition for the adoption of the protocol. For some previous
discussion on this issue see above cited messages, particularly the last
Essentially, the problem is that the server's signature key becomes a
"certifying key" for static DH keys and therefore its unauthorized usage can
lead to adversarially-chosen static DH keys that allow the attacker to fully
impersonate the server. This is not worse than an attacker stealing the
signature key and using it to impersonate the server in current TLS.
However, in the non-typical, but possible, scenario where an attacker can
access to the signing functionality as a black-box (i.e., without learning
signing key) and obtain a signature on a message of its choice, this becomes
a serious vulnerability. A particularly "ugly" case is that of a server that
hasn't even upgraded to TLS 1.3 but that can be impersonated as a TLS 1.3
server if the attacker gets a signature of the server on a static DH key of
the attacker's choice.

One clean solution to the problem is to equip servers with new certificates
that indicate use of the certified key for TLS 1.3. These can be either ECDH
certificates or signature certificates (RSA, ECDSA or your favorite
algorithm). In the case of ECDH certificates, no subcert or any form of
signature is needed to run OPTLS. If the server's certificate is for a
key then the server needs to send to the client a subcert with a signature
its static DH key. However, in this case, the certified key will only be
to sign subcerts - never as an online signature, hence can be afforded
protection. Indeed, the key can be stored offline and used only when new
subcerts (for new static DH keys) are needed, or it can be protected even
better by using it to to produce multiple subcerts (for multiple validity
periods and/or multiple EC groups) and then be destroyed. For those who
feel this is not secure enough, the choice is simple: Use ECDH certificates
and avoid the whole delegation issue. Note that ECDH certificates would be
simplest way of supporting a protocol like OPTLS. There is, however, one
with ECDH certificates, namely, a server will need multiple certificates to
support different groups. This is where server-signed subcerts are
Note, however, that this is an advantage only when using RSA signatures.
When the signature is ECDSA, we are back to the problem of requiring
ECDSA certificates for multiple groups. In this case, there seems to be no
advantage on having signature certificates. Fortunately, OPTLS can work with
any of these certificate types, leaving these choices to individual servers
and accommodating any future (possibly unforeseeable) preferences.

The bottom line is that the potential delegation vulnerabilities are
by servers obtaining new certificates for use with TLS 1.3. However, what
about a server that is interested to upgrade to 1.3 (e.g. for providing PFS)
but wants to keep using his TLS 1.2 signature key also with 1.3?
For this case, I proposed (see third message above) a small tweak to the
original OPTLS in which the server signs the static DH key together with the
client's nonce, hence preventing any form of delegation attack. This forgoes
the performance advantage of OPTLS relative to current TLS 1.3, but it
facilitates a transition period until a server acquires a new certificate
use in TLS 1.3. The nice thing about this tweak is that the only change in
protocol's spec is replacing the validity period in the subcert with the
client's nonce.  *Everything* else in the protocol stays the same; in
particular, it preserves all of the non-performance OPTLS advantages
(including optional 0-RTT support at no extra cost and a single logic for
the protocol modes). It also presents a real incentive for servers to
to TLS 1.3 (and TLS 1.3 certificates) as it saves the cost of RSA decryption
in each session. As we know, performance gains are a better motivator than
just added security.

*** OPTLS vs ECDSA ***

The argument was made that when people will start running TLS 1.3 (as
currently specified) with ECDSA, the dramatic performance advantage of OPTLS
relative to RSA signatures will diminish. That is true. But the OPTLS
advantages are well beyond performance. In particular, as said above, OPTLS
uses a single cryptographic mechanism, Diffie-Hellman, for all its
functionality and does not depend on signatures (except for certification).
Current TLS 1.3 depends on both DH and signatures, hence reducing its
to the weaker of the two.  In addition, 0-RTT cannot be supported with a
server's signature key and it requires adding a static DH key (or other PK
encryption keys) to the server's public keys. Hence the signature is
duplicating a functionality that can be provided by the static DH key only
OPTLS does). There are also specific problematic aspects with ECDSA. For
there is the issue of supporting multiple groups, hence necessitating
certificates (for the same "price", one can run OPTLS with ECDH
avoiding signatures, subcerts, and their associated complexities and costs,
including bandwidth).  ECDSA requires deployment at servers and clients (in
addition to ECDH that's needed for forward secrecy anyway), and presents
non-trivial implementation issues for performance and to resist side-channel
attacks (these implementation  problems are specific to ECDSA signing and do
not apply to ECDSA verification as may be needed for verifying
OPTLS avoids these obstacles by solely building on the necessary and
simpler-to-implement ECDH mechanism. Finally, ECDSA is vulnerable to the
compromise of the signing key upon the leakage of a single ephemeral
OPTLS does not suffer of this problem and actually increases security over
ephemeral DH key computed in TLS 1.3 by feeding g^{xs} into the KDF that
produces application keys.

I respectfully ask for the re-consideration of OPTLS by the WG as a possible
enhancement of TLS 1.3 design.