Re: [TLS] Fixing TLS

Dave Garrett <davemgarrett@gmail.com> Tue, 12 January 2016 19:39 UTC

Return-Path: <davemgarrett@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 89BF01A8755 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 11:39:20 -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 mJnas17s-8_Q for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 11:39:18 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 6A4D21A873A for <tls@ietf.org>; Tue, 12 Jan 2016 11:39:18 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id 6so358765494qgy.1 for <tls@ietf.org>; Tue, 12 Jan 2016 11:39:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=qwFQ5ehNFlwmpnP61vrz4Qerkw2iF1VN+NKec5nA5xw=; b=t956smEj2pizml0brCOJKSSPX8G9UJ2hWFjo26b5Dql5T8jCLsXRD9+PnQvgPJvmUS yj3SigOez78VCaLimIYixkBvyUL/62j0HBJgmxgllE0fEw2dWqqc8/f2tTyLWWRK7rFU MkTljrwBQ2MAKtx+X8ivUUAyNPnqZ7/OFVgfXm0IkTXNgq6rzn+GPonSIFd7BioE5icP H3x8HrI7sN7AB6xGDRYl4V2SXCT6VHA4J7PiSchfcKk7npnfJvkSOObCfsTnHDFzVoVo PA1LrEiVM4BFVF5Yta3e8v74bGwArial4LTDxegViz+9SULSfij4f2XqK3k7TuvWhril b8HQ==
X-Received: by 10.140.133.146 with SMTP id 140mr15172072qhf.99.1452627557569; Tue, 12 Jan 2016 11:39:17 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w75sm57431657qka.49.2016.01.12.11.39.16 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 11:39:16 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Bill Cox <waywardgeek@google.com>
Date: Tue, 12 Jan 2016 14:39:15 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> <CAH9QtQFASZENynns9=o-zHk=orfR6PcqKL9v5ByirmVcTQAQeA@mail.gmail.com>
In-Reply-To: <CAH9QtQFASZENynns9=o-zHk=orfR6PcqKL9v5ByirmVcTQAQeA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201601121439.15891.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dr-VXM6vTrwHHB44sRO50Jpl7Sg>
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:39:20 -0000

On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
> 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

Personally, I hope this new version of TLS, save for possibly some minor update & extensions, is the final version. I hope that Google's efforts to get QUIC as-is specced out go quickly and smoothly, and that it can be used as a basis to develop an official total TCP/TLS replacement. (the early documentation for QUIC was horrible, but the current work is vastly improved) As far as I'm concerned, TLS 1.3 is a transitional measure which should only be used in the medium-term by those who adopt new tech very slowly, and in the long-term phased out entirely. It is a very important transitional measure that needs to be done with as high a security and performance as possible, but a finite one nonetheless. (well, arguably, pretty much everything is, given a long enough timeframe ;) We have to get through the short-term to get to the long-term, though.


Dave