Re: [TLS] OPTLS: Signature-less TLS 1.3
Watson Ladd <watsonbladd@gmail.com> Fri, 07 November 2014 05:45 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 4676F1ACEE6 for <tls@ietfa.amsl.com>; Thu, 6 Nov 2014 21:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 yh-VLe2byZxH for <tls@ietfa.amsl.com>; Thu, 6 Nov 2014 21:45:21 -0800 (PST)
Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D649B1ACEEB for <tls@ietf.org>; Thu, 6 Nov 2014 21:45:20 -0800 (PST)
Received: by mail-yh0-f54.google.com with SMTP id t59so2122610yho.13 for <tls@ietf.org>; Thu, 06 Nov 2014 21:45:20 -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=QT3rUfMKdltQWUhulJmhaxWIfCXgEnwPW78VJrPlNjM=; b=inJuO1gyWH8f0r0EHbyZwmgovHziZap1qBxHvM6zUWULF8cPQfZPv9eJyLVqymiChQ TuLAqbm0YSLd5cA7NLxxhulbP+IO2bvYmC4aOn8Iuwul3bcnlZ6hyUzVekzV8VDEyKGs Fyi1eo1euBC7Bh++7nrLw4y8E8XsybaAyu4zNZWkokRxNLJStZzDttNJkE46NNO2vHIs HElaeRGPPlZ3zEnsvmI+dg+6jXWXJsXMGP0CSlE2qokTzx4qDptkuoYkpuxPOl/HgUq7 x/qOnRdPSBwu3qlrN79VZuVg381+apjZw5WNzOs0XT9kdExzuoCGtGgROHKwAbmTmjN7 S7cQ==
MIME-Version: 1.0
X-Received: by 10.236.30.197 with SMTP id k45mr8637860yha.163.1415339120173; Thu, 06 Nov 2014 21:45:20 -0800 (PST)
Received: by 10.170.195.203 with HTTP; Thu, 6 Nov 2014 21:45:20 -0800 (PST)
In-Reply-To: <545C3175.5070204@amacapital.net>
References: <CADi0yUObKsTvF6bP=SxAwYA05odyWdzR1-sWutrDLUeu+VJ1KQ@mail.gmail.com> <545C3175.5070204@amacapital.net>
Date: Thu, 06 Nov 2014 21:45:20 -0800
Message-ID: <CACsn0cmGvDTZyd3krrBmKgjijFBJh_gUZPoX-UEsE=1b2d0Ajg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BOtR14xUrQRC2NR28Ygo6TQzHfo
Cc: Hoeteck Wee <hoeteck@alum.mit.edu>, "tls@ietf.org" <tls@ietf.org>
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: Fri, 07 Nov 2014 05:45:26 -0000
On Thu, Nov 6, 2014 at 6:41 PM, Andy Lutomirski <luto@amacapital.net> 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. > > > > 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. > > --Andy > > _______________________________________________ > 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