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