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

Hugo Krawczyk <> Tue, 11 November 2014 14:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6A1EE1A8A89 for <>; Tue, 11 Nov 2014 06:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.323
X-Spam-Status: No, score=0.323 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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id scrBb1k9O68m for <>; Tue, 11 Nov 2014 06:47:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4A531A8A56 for <>; Tue, 11 Nov 2014 06:47:10 -0800 (PST)
Received: by with SMTP id gf13so9641157lab.31 for <>; Tue, 11 Nov 2014 06:47:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=e6ApVwHovfa0/gNc2vPKP97iSKfK+qLl7uff1Ux/QaA=; b=Wuv2T8Vvjzsu8Ri1aowiYCFTjNYoUqIxNxf02gcqfgbtPZiAkGFfigfe2YFu5EJKl6 IPaQU4gjxSm2DUVpnX6AMVoqGxmGpSmurRbc7SX8z19Z5lkInuiC6FpYP4ZjPahjlKN5 474S5pDTSmkmK0xVOJcGJ9vpWRNFWH4fKup3NrkitfzHHm1lOHmRgZVUklShwteSo6ZY 6RKb7Ph1zCpS7ZmK6Gh/EzEnO9tBVtJtFEpnRMmFobJiCYEe1YEmJdl7RczabuKVM6Kv He2YYrZwrnay0H3X06b8R1oMYqN8bUf55G0UwMCZkRGvpJ7QQoNE/gHgsyYWI3Dc1soz SCuA==
X-Received: by with SMTP id v1mr36520975lal.3.1415717228972; Tue, 11 Nov 2014 06:47:08 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 11 Nov 2014 06:46:38 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <20141111005220.GG3412@localhost> <> <20141111021201.GH3412@localhost> <>
From: Hugo Krawczyk <>
Date: Tue, 11 Nov 2014 09:46:38 -0500
X-Google-Sender-Auth: l9DdvnRhC2LaEgJVCcFqcmjBd9U
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a11c35626890f3a0507965a6b"
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: Tue, 11 Nov 2014 14:47:14 -0000

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

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