Re: [TLS] OPTLS: Signature-less TLS 1.3
Watson Ladd <watsonbladd@gmail.com> Thu, 06 November 2014 05:58 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 AB4C01A1A5B for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 21:58:29 -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 4hbw3ov-Pmeq for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 21:58:28 -0800 (PST)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B591A1A59 for <tls@ietf.org>; Wed, 5 Nov 2014 21:58:27 -0800 (PST)
Received: by mail-yh0-f51.google.com with SMTP id z6so1076553yhz.10 for <tls@ietf.org>; Wed, 05 Nov 2014 21:58:27 -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=08w81Anbo7dywmhfr5gU7QpHSYO8X1keXgHWPz3NHII=; b=1DnXwRv6l37RXF0kMEmKkMWn2n/FsEKipZjAjwYJO5B56H/pUyUfKcLny69/XvP553 nOIx9EO9nWmIDxKz5J3+q3JyaL4U5ymaNLffiHQAllH7foaKN1FdY4cXGRIsUtdEQBtS akjxzM9fp1cgDWN3C1GwMGlW1FxFZcsOoN9P1TkK3UTYYX9T+sY6phHjJ12S+WP7V5tN 8qrXMFNE10s0pF0ufVbkWONCui7SRUzEwrRaCAp8ERv9zvUwKF+wxRFGao1UTIbVFvsJ 8mU2s2hl8MTGyCxAb07fcMxYQswDdlICS8UNdnVgX2awyFmN+/GASVi6HghAbuM4QQnj xRHQ==
MIME-Version: 1.0
X-Received: by 10.236.7.52 with SMTP id 40mr1740799yho.172.1415253507232; Wed, 05 Nov 2014 21:58:27 -0800 (PST)
Received: by 10.170.195.203 with HTTP; Wed, 5 Nov 2014 21:58:27 -0800 (PST)
In-Reply-To: <CAK3OfOg-r=bV7mv7-arkgvd22Pqf91Q+qBKh7T2Oo6BBw8TL0g@mail.gmail.com>
References: <CADi0yUObKsTvF6bP=SxAwYA05odyWdzR1-sWutrDLUeu+VJ1KQ@mail.gmail.com> <CABcZeBNQBC1XXFR5sGo=V8WmxmL5thaBpeHSasy3SordbqNRTQ@mail.gmail.com> <CADi0yUMM6C=NpvFsc67J6Dc6uEO3OZ490tFWhAYmD362mC+D4A@mail.gmail.com> <CABcZeBNKpTMg+xhMK5TnO_W99MotoPw+_m9yrTqTUSwqyPpUPA@mail.gmail.com> <CACsn0cnkRZ5ZzX0bHfVFsvsrNoJxU2Txs0O2YW386fsg9GF1vQ@mail.gmail.com> <CABcZeBMQc5Mb_FK3davMxi0oBgzawqCMaYp1DqGYgg3nEHYHHw@mail.gmail.com> <CADi0yUOZ8LqsJbTTZmYL6XgrTjWvTMqvFMd7euzv+xQPU9vPJg@mail.gmail.com> <CABkgnnV1jcdXeZJ5BwZB1sM7xwuJt9Q3UUujTgddjC3sHDJxpA@mail.gmail.com> <CAK3OfOg5050v1sYH5o6rdLTT+_wLZ5R_b4yh7ZMPN=2NQ5W9wA@mail.gmail.com> <CACsn0ckjVDVcPokGPqFBtKC8uoMd+2m4Gp6xbVDfuq05dfz6Xg@mail.gmail.com> <CAK3OfOg-r=bV7mv7-arkgvd22Pqf91Q+qBKh7T2Oo6BBw8TL0g@mail.gmail.com>
Date: Wed, 05 Nov 2014 21:58:27 -0800
Message-ID: <CACsn0ckHxhkk-k6pR-_bmb4=JDWPz=x8ize+N=ownBdM_jVT5w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1UhXMJtLOTDzv0cxuSkCTTb2N94
Cc: "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: Thu, 06 Nov 2014 05:58:29 -0000
On Nov 5, 2014 10:01 AM, "Nico Williams" <nico@cryptonector.com> wrote: > > On Wed, Nov 5, 2014 at 11:56 AM, Watson Ladd <watsonbladd@gmail.com> wrote: > > On Nov 5, 2014 9:51 AM, "Nico Williams" <nico@cryptonector.com> wrote: > >> Perhaps we should pin latest datetime advertised by the server for > >> which other things are being pinned. This would prevent time travel > >> into the past. Time travel into the far future is, presumably, not > >> that big a deal, even with pinning, because server operators will > >> strive to make sure that doesn't happen. > > > > Or kernels can set the flag that stops this from being possible. We should > > note the issue, and, as with randomness, let the vendors solve it. > > User-land code can "correct" kernel time. For example, most Kerberos > libraries record time offset between the client and the KDC, and > correct local time when making AP-REQs for any service subsequently. > Clients trust KDCs, so that's OK. > > But if TLS clients also attempt to correct local clocks on the basis > of time advertised by arbitrary servers... Obviously, that's the > problem: TLS clients should not use the TLS protocol to attempt to > correct local clock skew. ?? No, the issue is that an attacker can fool NTP clients, and thus change the time on a computer. All we need to do is note the need for secure clocks, and let the implementor figure out how to get the right time. If there is an issue with NTP security, and there is, that's for the NTP WG to solve. That may be an OS issue: the same is true for the generation of random numbers. We already depend on secure time for OCSP stapling and certificate validity: I don't think Hugo's proposal is worse in that regard. We need to document the dependency, but whether water clock, sundial, atomic clock, pendulum clock, or RTC on the motherboard, we don't care how that is satisfied. Martin Thompson makes this same point upthread. I think the OPTLS proposal makes it extremely easy to host servers worldwide while keeping the certificate in a nice jurisdiction, or on a slow HSM while enabling performance enhancements as computers get faster. I think it resolves many longstanding security issues, and doesn't introduce any obvious new ones. (Of course, the cross-protocol attacks may be an issue: why data signed with the same key doesn't have a type pre-appended to it in the form of a UUID or similar is beyond me) It provides most of the tricky requirements like 0-RTT and privacy of certificates. It's genericly secure. It's a performance enhancement for sites that have avoided PFS until now because of performance issues. There's plenty of details to flesh out, and it may be that we find showstoppers that make the entire approach not work. But it would be a shame if we wasted another 6 months getting to this point by patching a protocol that is extremely hard to think about: there isn't a 0-RTT proposal on the table yet beyond this one. We still need to decide some details if we move forward, and hammer out the serialization and interaction with the TLS 1.2 negotiation that ensues when a TLS 1.3 hello is sent to a TLS 1.2 server (do we share group specifications? which extensions make sense and which don't? are ciphersuites going to be shared across the Client Hello? How do signature groups relate to the DH groups?) If I could start with a clean slate, it would be with this proposal. Yes, it's a major change. It doesn't solve all our problems. Some semantics, particularly around client authentication, will likely change. However, it has the great benefit of existing, and I hope we decide to build on it or find flaws that doom it. Sincerely, Watson Ladd > > Nico > --
- 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