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

Andy Lutomirski <> Fri, 07 November 2014 06:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC6171ACEF9 for <>; Thu, 6 Nov 2014 22:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zo0L0eQSyyUE for <>; Thu, 6 Nov 2014 22:21:48 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F2C61ACEF8 for <>; Thu, 6 Nov 2014 22:21:48 -0800 (PST)
Received: by with SMTP id q1so3901074lam.38 for <>; Thu, 06 Nov 2014 22:21:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VMSrOhdKU5tmKpmaKcZCZwFeJS72nRrL+Jptjz3KZvU=; b=BnFr2f8c0FFCTN5/6dd5HmEFV/1xncMdo+cajBfHZRxK+0L954P9aRPS0GxbbhlDb3 rZOk6Z5L07/izeItLHoHrlD+RFytVollGFnzNVxDHvjfHj47svLOMru9OIKN1VM96MVT 9VozLqbROwvgxrVkl51SeuRTjqSi8xLmd5lVmzcQi8Jue1emIpn9fTcwo5IhsLTCZdjB z5I7oO1rD51ZhYL1lBufpnhUMs1K0zd52Kj1LwBaO/34kdRLkPvBK2rwriqjC7SIsP0h QOVetkVpyIl5YacWYUcZbRJpBh5Oy6czLqRHle9UYlga/xtnmbTjyITNz3LN+TclG35A 71pQ==
X-Gm-Message-State: ALoCoQkXOt3gWT4GF/Yp0/ZuFFRREu3TlbTAgeTxVwCSsbajBzmXkd/qbAEMC0aLkp58qqh1U+Xc
X-Received: by with SMTP id o6mr9547005lao.4.1415341306638; Thu, 06 Nov 2014 22:21:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 6 Nov 2014 22:21:26 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Andy Lutomirski <>
Date: Thu, 06 Nov 2014 22:21:26 -0800
Message-ID: <>
To: Watson Ladd <>
Content-Type: text/plain; charset="UTF-8"
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: Fri, 07 Nov 2014 06:21:54 -0000

On Thu, Nov 6, 2014 at 9:45 PM, Watson Ladd <> wrote:
> On Thu, Nov 6, 2014 at 6:41 PM, Andy Lutomirski <> wrote:
>> On 10/31/2014 05:54 PM, Hugo Krawczyk wrote:
>>> During the TLS interim meeting of last week (Oct 22 2014) I suggested
>>> that TLS
>>> 1.3 should abandon signature-based authentication (other than for
>>> certificates)
>>> and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
>>> static Diffie-Hellman for authentication. This has multiple benefits
>>> including
>>> major performance gain (by replacing the per-handshake RSA signature by the
>>> server with a much cheaper elliptic curve exponentiation), compatibility
>>> with
>>> the mechanisms required for forward secrecy, natural accommodation of a
>>> 0-RTT
>>> option, and a simple extension without signatures for client authentication.
>> I like this idea a lot.
>>> Note on certificates: Since in current practice servers hold
>>> certificates for
>>> RSA signature keys rather than for static DH keys, the certificate field
>>> in the
>>> above protocol will be implemented by a pair consisting of (i) the
>>> server's RSA
>>> signature certificate and (ii) the server's signature using this RSA key
>>> on the
>>> server's static public DH key g^s. The latter signature by the server is
>>> performed only when a new static DH key is created (how often this
>>> happens and
>>> how many such keys are created is completely up to the server - it has the
>>> advantage that these keys can be changed often to increase security against
>>> leaked keys). This use of RSA also enjoys the high efficiency of RSA
>>> verification for the client.
>>> The handling of Client certificates would be similar.
>> I would like to see one modification of this: I think that the
>> certificate should be (RSA/ECDSA certificate, server's long-term DH
>> share, expiration), signed by the cert.  That way any user of a
>> certificate can sign short-term shares instead of long-term shares,
>> significantly reducing the impact of a leak.
> Note that in the above proposal, long-term can be entirely defined by
> the server or client as the case may be. I feel I'm missing something
> here.
>> It would be even better if there were a way to limit one of these things
>> to a certain host.
> The client cert that is? I'm not sure what this gets you: we know how
> to use certs securely.

Sorry, I wasn't very clear.  My thought is that, if we're going to
introduce a new object signed by the PKIX cert, such that a server
only needs the private key associated with that object and not the
certificate's private key, then we should take advantage of this to
add some features.  In particular, we should let it expire before the
certificate, and I think we should allow it to be pinned to a
particular hostname or maybe set of hostnames.  The former was covered
elsewhere in this thread.  The latter was not.

Also, ha ha ha ha.  We know how to user certs securely.  Yeah, right.

If I buy a cert for *.my.domain, I want to be able to provision with some secret that lets it act as but
not  Since the PKIX people seem to be completely unable
to address this, pinning DH shares to a domain would solve the problem
without involving any PKIX changes.

>> That being said, I do have one significant concern with this: what
>> happens when someone builds a quantum computer?  I don't expect TLS 1.3
>> to be post-quantum secure, but I would like the road to replacing
>> primitives for post-quantum security to be reasonably clear.
>> Unfortunately, I'm not aware of a credible post-quantum DH-like
>> construction.  On the other hand, post-quantum signatures are
>> straightforward if rather large right now, and post-quantum public-key
>> encryption is, as far as I remember, not guaranteed to be a drop-in
>> replacement for DH.
>> Will this end up being a problem?
> If supersingular isogeny volcanoes are secure, it won't be a problem.
> NTRU for old TLS is also a possible backup plan.

The former is a big if, and it makes me nervous to say that, if
someone builds a quantum computer, that TLS 1.2 might be better than
1.3.  And my inner pundit expects NTRU to fail as soon as anyone
pushes it hard.

That being said, this may not be a big deal -- I suspect we'll have
*something* that fits in this framework.