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

Hugo Krawczyk <hugo@ee.technion.ac.il> Thu, 13 November 2014 17:39 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 7B9721A8AE9 for <tls@ietfa.amsl.com>; Thu, 13 Nov 2014 09:39:00 -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 NactdBAt4Kjx for <tls@ietfa.amsl.com>; Thu, 13 Nov 2014 09:38:57 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EEA1A8F4D for <tls@ietf.org>; Thu, 13 Nov 2014 09:38:44 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id 10so11484438lbg.14 for <tls@ietf.org>; Thu, 13 Nov 2014 09:38:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=wFjAGJdV7keGtKLP03oPtFb5ilhEwqIDn1X+oOKOo8s=; b=TVy9Et9ZPdZI9fPjXDulyMDfeVTNyv8j2REC53zjePQm/jnxBqgCzHliqHhSGJSSpw mPjj85Kdr5jFP2bHER8ipTBHxllL4rxFb4C2qfQ0JoznVcZm6pZgjS7jndJm/Q4Gk4OL DWhODrELnADDpB0NizKNsX5gL5heq2XyZkkmr5LUQz2Akp0iZgmNxhN9v95N2MmRZ1L1 375YCLaJrnJ9qwsgnuRiNmzf0jVPP072lQrB1RsK4mAe7wdyYjXUsPoizvXmOLFMXkO9 cDRVhFklpovudO5qMc601D0vd0fFo9QaWoieDOKEbednfzSWH76E1jW0y1PD7MtD67iy G67g==
X-Received: by 10.152.7.193 with SMTP id l1mr3606734laa.57.1415900322823; Thu, 13 Nov 2014 09:38:42 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.78.20 with HTTP; Thu, 13 Nov 2014 09:38:12 -0800 (PST)
In-Reply-To: <CACsn0c=J-0sB5uyBBuf9tqmviD2CGF3e+PhQt_gcxm2EQfcfjw@mail.gmail.com>
References: <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> <20141111173325.GK3412@localhost> <4008860D-58A7-4A48-A4FC-A5823D94B791@gmail.com> <20141111203740.GN3412@localhost> <CADi0yUOELWqkOrrYh24Kcaiz8h27DxC=a5X4piLwxyr2N-1SqQ@mail.gmail.com> <CACsn0c=J-0sB5uyBBuf9tqmviD2CGF3e+PhQt_gcxm2EQfcfjw@mail.gmail.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Thu, 13 Nov 2014 12:38:12 -0500
X-Google-Sender-Auth: jadpvtwM7TVODdbnlTH-eQaY1jA
Message-ID: <CADi0yUOxahwQxyhOd+W1N=Crz5eL8_p8H4OHwUNgDOrSgU5HSA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c23dbcc7838b0507c0fbcf"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tHwGIa3z7_cWxw2NVFijgAfL68g
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: Thu, 13 Nov 2014 17:39:00 -0000

I am a bit hesitant to bring a new idea immediately before the meeting today
but since I won't be there I would like to mention it in case people find it
useful. I will be happier with the direct adoption of OPTLS but the idea
below
addresses the delegation concerns at some extra (temporary) cost.

The idea is to build OPTLS in a way that allows to use it in two "modes":
In the regular mode (r-mode), the protocol is exactly  OPTLS as proposed
originally in the first message of this thread
http://www.ietf.org/mail-archive/web/tls/current/msg14385.html.
It enjoys all the benefits of OPTLS including avoiding online signatures.
It also avoids most concerns with delegation when servers have TLS 1.3
certificates (more on this below).

A second mode, call it "transitional mode" (t-mode), is appropriate for
servers that use the same certificates for TLS 1.2 and 1.3 and completely
avoids the delegation concerns. The price for this variant is one more
exponentiation relative to the cost of the current TLS 1.3 specification.
This extra cost is not nice but is not huge either: As a percentage of the
performance cost of current TLS 1.3 spec (two exponentiations for PFS and a
online RSA signature), the addition of one EC exponentiation is relatively
minor (<10% ?).
This t-mode works as in OPTLS but replaces the validity period of the
subcert
with the client nonce. That is, the subcert
sign-rsa(g^s, T1, T2, stuff)
used in OPTLS (where T1, T2 indicate the limits of validity period and
sing-rsa indicates a server's signature using his certified signing key)
will be replaced with
sign-rsa(g^s, client-nonce, stuff).
The rest of the protocol stays the same.
Thus t-mode preserves the current online signature, preempts the delegation
concerns, but costs one more exponentiation (g^{xs}) relative to current 1.3
spec. The cost of the t-mode stays the same as the original OPTLS in the
cases
of 0-RTT, PSK or session resumption.

So why am I saying that TLS 1.3 specific certificates will address the
delegation concerns? First, by "TLS 1.3 specific certificates" I mean
certificates (typically RSA or ECDSA) that have an indication of use for TLS
1.3 (I assume such indication can be accommodated in certificates).
In this case, a server can use the signing key to only sign static DH keys,
hence the signing key is never used online. This allows for a better
protection of the key (the concerns with delegation stemmed from temporarily
vulnerable keys). Moreover, as I indicated in a previous email, a server can
even use this signing key to sign multiple static keys (for multiple groups
and/or multiple validity periods), securely store these DH keys, and destroy
the signature key. Why do these certificates have to be TLS 1.3 specific
(i.e., have an indication in the certificate that this is for use in TLS
1.3)?
Because clients need to know when to accept the protocol in r-mode or run it
in t-mode. The idea would be that clients accept the former only with
1.3-enabled certificates.

Interestingly, this approach supports "sound economics": It is the interest
of
the server to move to r-mode in order to save on the cost of online
signatures
hence it has a motivation for paying for the extra TLS 1.3 certificate...

Hugo

On Thu, Nov 13, 2014 at 10:42 AM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Wed, Nov 12, 2014 at 8:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
> wrote:
> ><snip>
> >
> > * Assuming that servers will not want to get certificates for use with
> TLS
> > 1.3
> >   only (why not?), then we need to address the above subcert forgery
> > scenario
> >   where the atacker gets limited access to the signing key. An imperfect
> but
> >   effective solution is to only issue subcerts with short validity
> period,
> >   i.e.  where the difference T2-T1 is small. In this case the attacker
> with
> >   temporary access to the signing key can only create a limited number of
> >   subcerts covering a limited time span.
> >
> > Operational note: It is the servers' responsibility to create such
> > short-lived
> > subcerts but it is the clients' responsibility to check the subcerts are
> > indeed short-lived (otherwise an attacker can generate a long-lived
> subcert
> > that the client will accept).
> >
> > * Clients with clocks with significant deviations from the correct time
> will
> >   have trouble accepting valid subcerts and may be induced to accept old
> (or
> >   into-the-future) subcerts. I can imagine this to be a problem. But is
> it
> >   enough to abandon the benefits of a ECDH-based solution like OPTLS?
>
> I don't think this is quite right. An attacker might root a box
> connected to an HSM, and sign several thousand short term shares: to
> the HSM this looks like the website being popular, and will cover a
> large range of time. There doesn't seem to be an easy way to limit the
> time the signature was made, and such a limitation could be
> counterproductive in some scenarios. However, I don't think this is a
> real problem: HSM usage on major sites is extremely low, and OPTLS
> makes it easier.
>
> Sincerely,
> Watson Ladd
> >
> > On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams <nico@cryptonector.com>
> > wrote:
> >>
> >> On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote:
> >> > > On Nov 11, 2014, at 7:33 AM, Nico Williams <nico@cryptonector.com>
> >> > > wrote:
> >> > > That the "sub-cert" needs either a revocation scheme (not likely)
> or a
> >> > > short lifetime.  The latter puts this on a par with session
> >> > > resumption,
> >> > > thus making one (well, me) wonder what the advantage to the static
> DH
> >> > > concept would be.
> >> >
> >> > There is a revocation scheme. If the private ECDH key is lost, you
> >> > revoke the certificate, thereby invalidating the delegation.
> >>
> >> Ah, good point!
> >>
> >> > > We could put static DH keys in DNSSEC and learn them that way, which
> >> > > would get us 0rt.
> >> >
> >> > Another possibility is to place the ECDH public key in a certificate
> >> > extension. This gives it a lifetime as long as the certificate, and it
> >> > doesn’t matter whether the “regular” certificate public key is RSA or
> >> > ECDSA or anything else.
> >>
> >> Sure, certs could have multiple subject public keys.  That'd be a very
> >> nice.  A cert could have an encryption key, a different signature key,
> >> and a key agreement key.
> >>
> >> > It removes the need to use signatures at all by the server. Not even
> >> > once.
> >>
> >> Yes.  I like this.
> >>
> >> Nico
> >> --
> >
> >
> >
> > _______________________________________________
> > 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
>