Re: [TLS] Fixing TLS
Bill Cox <waywardgeek@google.com> Tue, 12 January 2016 19:27 UTC
Return-Path: <waywardgeek@google.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 CF2821A8742 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 11:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 FGA81_fRme8f for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 11:27:03 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168031A8735 for <tls@ietf.org>; Tue, 12 Jan 2016 11:27:03 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id t15so128465632igr.0 for <tls@ietf.org>; Tue, 12 Jan 2016 11:27:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Teffki3v+RnVSS7lLijnoW0ztU5yxnI71fvrdqMnkHk=; b=gUqO/XhqBZjyP0C4AlYV/rhc+kBbM7I7d0RsI1rxkwCUSwgdhUOvSSHFJU8awCd5Z0 rKx+A2Tac7jZvpcn2a5ANtw2SiXl9mMJmghgqJwM906IdjDE8G44sHWvorIEYuUT/UIa pd/Y3RsUun0vVhCr54CRI6Ywr+N76rZ0ck8zggqI4RmgcozuoGO5fsDA2ACirfpUs6Y9 5eq8lWhFv4KkeW45sEiyWqgQZS/Oikx7DdXjqsGXHVpfGWbLsaTyVEs3mCqJxQDJhn9x Oxkvahj3PnpXEptyXW5Q6MN5N3YjSnLXADfZaRl5YMNDNVxPSeobbf3qaP/OiRwj0ZIR t5/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Teffki3v+RnVSS7lLijnoW0ztU5yxnI71fvrdqMnkHk=; b=NBhOAhZJrciWllf8f/uju1+j3CWdydtRnyyMLaXLxAcgHb0sLzM8DQf7h3ImEvCzXs ++o1H/nyZ3QNOX+Y01GGQkYhrxe7YFebme0j7rQX29Q4nD7N+ayTTr3O39MFcHz6ugFx Ul81X+KsQq99b1S5ubQbPYEpj094qI/G7xXZeYoVI4KTjdOSaq8fIARyQ83lyuX0b+a6 5SUBl6zNaUmekpvUW71IA7MCVXbXJuqofzGYo9yndsVZzsh9glcTzUkjnc4DjsKrJHF/ J4PdwpToKYWvumVnDWEY+ftYJvcjNvWHUN1Fh0jnEWeVcEU9if0juKWnxXo3DikDx+50 K1RQ==
X-Gm-Message-State: ALoCoQlK6ptuqvjlaE1YiXJsNsEUEvhRNRZsD4oSS33ijm5BWsz14RUPpWgXoEpCUE6YahqnAyT/Y7vwTOJ3J4UGE46m915zXvS+kz+umhv2yXs7tsLMMhA=
MIME-Version: 1.0
X-Received: by 10.50.85.107 with SMTP id g11mr7087300igz.4.1452626822366; Tue, 12 Jan 2016 11:27:02 -0800 (PST)
Received: by 10.107.141.12 with HTTP; Tue, 12 Jan 2016 11:27:02 -0800 (PST)
In-Reply-To: <201601121202.26624.davemgarrett@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com>
Date: Tue, 12 Jan 2016 11:27:02 -0800
Message-ID: <CAH9QtQFASZENynns9=o-zHk=orfR6PcqKL9v5ByirmVcTQAQeA@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="089e0149bb02bd51e0052928099a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wum1NpCYltTHJ5d-XSqnW9kj-7I>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fixing TLS
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 12 Jan 2016 19:27:05 -0000
On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <davemgarrett@gmail.com> wrote: > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > > I'll be the bearer of bad news and tell you that your proposal has come up > in multiple forms. I suggested a similar thing a while back and far before > me others have as well. The chairs have, however, long declared consensus > that we want to focus on a single new version not leaving out other more > complex changes, namely latency improvements. The primary argument is that > TLS version adoption rates are horrible and we would be far better suited > to one major upgrade rather than incremental changes that would likely > inhibit adoption of the more complex changes that we also need. (just a > quick summary from my view; someone else can chime in here if they need to) > > I can't dispute this position, though personally I think it's not the best > move. That said, if we were going to do a more incremental TLS version, > doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up > with would have been the way to go. That ship has sailed, and we're now > well into TLS 1.3 development, so I guess I'm now on board with working to > finalize the work that we're already doing (frankly, with a rename to TLS > 2.0 being a good idea). If you can somehow drum up consensus to overturn > the previous consensus, more power to you, but I think that's not likely to > be the best route anymore. > I'll just second what David said here. 0-RTT mode is here to stay, and I don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is a huge upgrade for users. The trick is doing this securely... My opinion counts little here, and TLS 1.3 is already nearly completely defined, so I think it is too late for this discussion. However, if it were not... A clean-slate TLS 2.0 which reuses as little as possible, and simplifies life as much as possible, would have been preferable, IMO. I look at the QUIC crypto code and then go back to the TLS/SSL code, and there is a night and day difference in complexity. I think it is going to be painful for some of us to watch the simple, clean QUIC crypto code move to the archives and get replaced with TLS 1.3, which is surely going to be a substantial bolt-on of code to the existing TLS 1.2 code base. It takes a super-genius just to see all the potential pitfalls in the TLS 1.2 code as it is. I think it will be even harder to analyze after the TLS 1.3 bolt-on. Fortunately, we seem to have a large number of super-geniuses working in TLS, much of the present company on this thread included :) However, if I personally were making changes to the code, it would be maybe 4X faster to do it in QUIC crypto, and 4X more likely that I would not introduce a critical bug in the process. I think it is natural for many members of this email list to discount this complexity issue in TLS 1.2/1.3, since many of the most brilliant programmers see the existing code as not all that complex. For regular mortal programmers out there like me, we would very much appreciate a clean-slate effort with minimal complexity, and there are a lot of lessons you folks have learned over the years that could be included. Maybe next time, in TLS 1.4? :-p Bill
- [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Yoav Nir
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Peter Bowen
- Re: [TLS] Fixing TLS Watson Ladd
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Peter Bowen
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS David Benjamin
- Re: [TLS] Fixing TLS Bill Cox
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Andrei Popov
- Re: [TLS] Fixing TLS Bill Cox
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Tony Arcieri
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Kurt Roeckx
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Watson Ladd
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Nikos Mavrogiannopoulos
- Re: [TLS] Fixing TLS SCHWARZ, Albrecht (Albrecht)
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Dmitry Belyavsky
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Salz, Rich
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Martin Rex