[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.112.247.43 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 10.25.78.135 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 not 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 proper consideration, in particular, since there was not enough time to digest the proposal before the Honolulu meeting. I believe that OPTLS offers significant 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 in 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 clarifications. *** 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 *forward-looking* 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: https://www.ietf.org/mail-archive/web/tls/current/msg14385.html https://www.ietf.org/mail-archive/web/tls/current/msg14592.html https://www.ietf.org/mail-archive/web/tls/current/msg14601.html *** 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 raised in this list and therefore I see its resolution as a necessary (and hopefully sufficient) condition for the adoption of the protocol. For some previous discussion on this issue see above cited messages, particularly the last one. 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 gain access to the signing functionality as a black-box (i.e., without learning the 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 signature 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 signing key then the server needs to send to the client a subcert with a signature on its static DH key. However, in this case, the certified key will only be used to sign subcerts - never as an online signature, hence can be afforded better 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 still 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 the simplest way of supporting a protocol like OPTLS. There is, however, one issue with ECDH certificates, namely, a server will need multiple certificates to support different groups. This is where server-signed subcerts are convenient. 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 multiple 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 addressed 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 for use in TLS 1.3. The nice thing about this tweak is that the only change in the 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 all the protocol modes). It also presents a real incentive for servers to upgrade 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 security 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 (as OPTLS does). There are also specific problematic aspects with ECDSA. For one, there is the issue of supporting multiple groups, hence necessitating multiple certificates (for the same "price", one can run OPTLS with ECDH certificates, 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 certificates). OPTLS avoids these obstacles by solely building on the necessary and simpler-to-implement ECDH mechanism. Finally, ECDSA is vulnerable to the full compromise of the signing key upon the leakage of a single ephemeral quantity. OPTLS does not suffer of this problem and actually increases security over the 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. Thanks, Hugo
- [TLS] Re-thinking OPTLS Hugo Krawczyk
- Re: [TLS] Re-thinking OPTLS Martin Thomson
- Re: [TLS] Re-thinking OPTLS Hugo Krawczyk
- Re: [TLS] Re-thinking OPTLS Martin Thomson
- Re: [TLS] Re-thinking OPTLS Watson Ladd
- Re: [TLS] Re-thinking OPTLS Salz, Rich
- Re: [TLS] Re-thinking OPTLS Adam Langley
- Re: [TLS] Re-thinking OPTLS Hugo Krawczyk
- Re: [TLS] Re-thinking OPTLS Hugo Krawczyk
- Re: [TLS] Re-thinking OPTLS Eric Rescorla
- Re: [TLS] Re-thinking OPTLS Hugo Krawczyk
- Re: [TLS] Re-thinking OPTLS Nico Williams
- Re: [TLS] Re-thinking OPTLS Hugo Krawczyk
- Re: [TLS] Re-thinking OPTLS Hugo Krawczyk
- Re: [TLS] Re-thinking OPTLS Nico Williams
- Re: [TLS] Re-thinking OPTLS Nico Williams
- Re: [TLS] Re-thinking OPTLS Hoeteck Wee