Re: [TLS] OPTLS: Signature-less TLS 1.3
Watson Ladd <watsonbladd@gmail.com> Tue, 11 November 2014 14:59 UTC
Return-Path: <watsonbladd@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 033561A8A9B for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 06:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Level:
X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, J_CHICKENPOX_46=0.6, 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 PIcM2atfFJEk for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 06:59:37 -0800 (PST)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F6C1A8A95 for <tls@ietf.org>; Tue, 11 Nov 2014 06:59:37 -0800 (PST)
Received: by mail-qg0-f44.google.com with SMTP id q107so7275012qgd.17 for <tls@ietf.org>; Tue, 11 Nov 2014 06:59:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RCiVAphM3YNHNl8VbOJnAi+xMXBh2jKbJJnu5MDB8SA=; b=Xn5n5py+k3DuSHj+rlHKc2YTJwUDDMwnZWnmGm8GKq48WnCQGy/0UdLw6o0LWc7Wqo EyjXis9XibXBGRWvra55ePCNMeZoolq2MKmgEOA32Wdj4mYsdlukLEGI+jCFKQ07SYRG 5gJ6SYM7pzWz8YvLTP6Va9PxaxHWeQ5CnucM/3RQJWyUA/JUhVhMkMKxn+J7AyHgrD3M PclNxTJ9DnV879eL3qYQnuvUvqQ0/JlTI8jzEpcyyqpS2+REaSQFa+z2Tcj1oVZosq/x X6e13aUUfqnXF1rZHnz4DAqbjtjVmx4h5d32oeMFk9JChonsvjWSmOddt05SMoEW03s1 t1uA==
MIME-Version: 1.0
X-Received: by 10.140.94.85 with SMTP id f79mr50593934qge.50.1415717976804; Tue, 11 Nov 2014 06:59:36 -0800 (PST)
Received: by 10.140.20.199 with HTTP; Tue, 11 Nov 2014 06:59:36 -0800 (PST)
In-Reply-To: <CADi0yUO4Q8=FkmAXH0na2gd6MADb4JSCGUGju7mYYm-qxqEKQw@mail.gmail.com>
References: <CADi0yUOZ8LqsJbTTZmYL6XgrTjWvTMqvFMd7euzv+xQPU9vPJg@mail.gmail.com> <CABcZeBM+CcG8Tr_+XZ6nkw4xJP8DGFXguvRvLGhTUXYdhEOUqA@mail.gmail.com> <87r3xdfzi1.fsf@alice.fifthhorseman.net> <CABkgnnWqppL-1VJORYfrwuKn8n=NO-rZX6LDTiq+-qxddsp1mg@mail.gmail.com> <87r3xawv8a.fsf@alice.fifthhorseman.net> <CABkgnnXWAZ78ir-62cnsZM080GAFzScNSv52SKGAc6ZRYM+++w@mail.gmail.com> <CACsn0c=nh1yDUcYGYSMBhUs0OnJJJeOh5CRT3qyz8ZEVQsdokA@mail.gmail.com> <54615526.5020504@fifthhorseman.net> <20141111005220.GG3412@localhost> <8C76E955-0942-4343-B044-8E490C6264FB@gmail.com> <20141111021201.GH3412@localhost> <5461A3DD.4030102@fifthhorseman.net> <CADi0yUO4Q8=FkmAXH0na2gd6MADb4JSCGUGju7mYYm-qxqEKQw@mail.gmail.com>
Date: Tue, 11 Nov 2014 06:59:36 -0800
Message-ID: <CACsn0c=vwwqRoCrsq=QGu3xiQFNKV+rf+3Sb-NYbWuD+JYtHKw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8kqk_s2vd-eLRWBRX2p9EtJHtPg
Cc: "tls@ietf.org" <tls@ietf.org>, Hoeteck Wee <hoeteck@alum.mit.edu>
Subject: Re: [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: Tue, 11 Nov 2014 14:59:40 -0000
On Tue, Nov 11, 2014 at 6:46 AM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote: > Wait, wait, wait... > > I am surprised to see such an abrupt decision to drop consideration of > OPTLS. There is little information in the minutes as for the rationale for > this move although it seems to be entirely based on the handling of > static-DH certificates and the understanding that in the future one can > still run TLS 1.3 with ECDSA and/or ECDH certificates. > > Let me address these issues and the multiple advantages of OPTLS that need > to be considered. Please bear with me in spite of the long email. Since I > will not be in Hawaii (I wish I was...) take this in lieu of a presentation > at the WG meeting (and pardon the advertisement pitch, I believe it is fair > and well-founded). > > First, note that if we had ECDH certificates then this whole issue of how to > sign the static DH key g^s would be moot. You would use that certificate to > vow for the server's static DH key. Security would be based on the > protection of s exactly as it is based on the security of a private signing > key today. In particular, the key s would need to be kept online with the > same vulnerabilities (and potential protection) of a signing key today. > > The whole reason to create a "sub-certificate" for g^s by signing it with > the server's certified signature is that we currently only have certificates > for signature keys, not ECDH. This may or may not change in the future - > actually, as I argue below, there are advantages of sub-certs for g^s over a > long-term ECDH certificate. > > So what is the concern that has been voiced regarding the use of sub-certs > for g^s? That the leakage of a private key s that was sub-certified allows > to impersonate the server for the validity period of that sub-certificate, > and that clients with skewed clocks will be accepting it beyond the intended > validity period. This is true but not different than the situation with > current certificates. In particular, the validity period of the sub-cert > will never exceed that of the signing certificate. How about revocation? It > requires the main certificate revocation exactly as needed now. > > So none of these issues is worse than vulnerabilities of signing keys today. > Actually, there are two non-trivial advantages to the sub-cert approach: > - clients with good clocks (or small skews) will not accept g^s much past > its validity period, which would be typically much more limited than the > main signing cert. Clients with terrible skews will never be in worse shape > than they are today with respect to validating the signing certificate. > - a server can issue multiple g^s keys for availability, distribution, > sub-domain use, etc. and to support different groups ECDH groups - which > need to be supported anyway for PFS also in a signature-based protocol. > (There is also the ability to support online retrieval of currently > validated sub-certificates via protocols such as DNSSEC or other specific > mechanisms, even though there seems to be little enthusiasm for this option, > at least currently) > > The only downside I can see for sub-certification of g^s is for cases where > protection of an online signature key (as needed today) is better than the > one affordable to the key s, e.g. with current HSMs that support signing but > not ECDH. But this is the price of a looking-forward transition period as > opposed to proposals that keep us tied to the sub-optimality of past > solutions. It needs to be considered in light of the many advantages of a > signature-less protocol as claimed here. > > Let me now address the claim that in the future we will have ECDSA > certificates which would enable a signature-based protocol with less cost > than RSA signing today. This claim is mostly true but ignores some important > aspects of the use of ECDSA: > - The wide use of RSA in certificates is not going away any time soon - so > the very significant performance advantages of OPTLS vs a RSA-implemented > signature-based protocol is going to be enjoyed for long time (actually, it > may be a main motivation for adoption of signature-less TLS 1.3 in addition > to PFS) > - The total time of sign+verify in ECDSA is larger than the time of > static-DH authentication used in OPTLS. > - ECDSA presents definition and implementation complexities that do not > exist with ECDH, in particular tied to specific EC groups. In particular, > this is likely to postpone adoption of ECDSA. > - Online ECDSA signatures amplify the vulnerability of the long-term ECDSA > signing key to the leakage of ephemeral values (in ECDSA, as in other > Schnorr-like signatures, there is a per-signature random value that if > revealed, it fully reveals the long-term private signing key). Such > vulnerability does not exist in OPTLS. > - Signature-less protocols have a privacy advantage in providing plausible > deniability, especially when compared to protocols (as current 1.3) that > sign the peer's identity (I wrote on this in a previous message to this > list). > In addition, signature-less protocols can take advantage of sub-certs as > noted above. Even when the algorithm to sign these sub-certs will be ECDSA, > it will allow the use of Offline ECDSA hence ameliorating the above > vulnerability of ECDSA to ephemeral disclosure. > > And now to summarize some of the general advantages of ECDH-based (and > signature-less) protocols and some specific advantages of OPTLS: > - 0-RTT support required static ECDH keys (or semi-static, exactly as in > OPTLS) - thus in a signature-based protocol this support would be pure > overhead > - Critical performance gain relative to per-session signing with RSA (an > advantage that will most probably stay with us for long time) > - Compatibility with the already needed mechanisms to provide PFS (hence > amortizing any cost of the underlying crypto) > - Compatibility with pre-shared key authentication: simply replace g^{xs} > with PSK. > - Cryptographically, it relies on the ECDH security of the underlying EC > groups rather than relying on this security PLUS the security of signatures > (which means relying on the weaker of the two primitives) > - Other advantages mentioned above: Sub-cert time limitation and support for > multiple static ECDH keys if so desired, specific advantages with respect to > ECDSA-based protocols (complexity of ECDSA and vulnerability to ephemeral > information), privacy via deniability, offline signatures (specially > significant with ECDSA). > > Finally, the advantage of a protocol built with cryptographic logic, not as > a accidental result of many years of patches. I believe the WG has delayed > or never implemented in the past significant changes such as > Encrypt-the-MAC, OAEP, CBC IVs, session binding, etc. This time we can make > it right from the begining. I agree with what you say here: we need to get it right. However, EKR privately pointed out the following: once TLS 1.3 based on OPTLS is deployed, a user of TLS 1.2 who puts their private key in an HSM has a problem. If an attacker gains control of the box connected to the HSM they can sign a credential that permits permanent impersonation, and can do so even without the user upgrading to TLS 1.3. I don't think this is a major problem, and if we address it, it should be by designing a protocol that avoids it, not by hacking and patching TLS 1.2. Sincerely, Watson Ladd > > Hugo > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Rene Struik
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Rene Struik
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Ilari Liusvaara
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Manuel Pégourié-Gonnard
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hanno Böck
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Peter Gutmann
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Martin Thomson
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Martin Thomson
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Martin Thomson
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Andy Lutomirski
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Andy Lutomirski
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Daniel Kahn Gillmor
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Daniel Kahn Gillmor
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Martin Thomson
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Daniel Kahn Gillmor
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Martin Thomson
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Eric Rescorla
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Yoav Nir
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Daniel Kahn Gillmor
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Yoav Nir
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Daniel Kahn Gillmor
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Yoav Nir
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Nico Williams
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Salz, Rich
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Watson Ladd
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Salz, Rich
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Dan Brown
- Re: [TLS] OPTLS: Signature-less TLS 1.3 Hugo Krawczyk