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