Re: [TLS] Fixing TLS

Hubert Kario <hkario@redhat.com> Wed, 13 January 2016 11:44 UTC

Return-Path: <hkario@redhat.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 AACB21A86DD for <tls@ietfa.amsl.com>; Wed, 13 Jan 2016 03:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 D7Dy9zxesU1T for <tls@ietfa.amsl.com>; Wed, 13 Jan 2016 03:44:32 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551C81A7D84 for <tls@ietf.org>; Wed, 13 Jan 2016 03:44:32 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A985AC09FA8F for <tls@ietf.org>; Wed, 13 Jan 2016 11:44:31 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0DBiU41022602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 13 Jan 2016 06:44:31 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 13 Jan 2016 12:44:24 +0100
Message-ID: <2188470.QJNceayIVJ@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <201601121514.14360.davemgarrett@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <BLUPR03MB13968C36D7067208424946018CCA0@BLUPR03MB1396.namprd03.prod.outlook.com> <201601121514.14360.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart14530835.UFk19S31L8"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/spSTamqfCYet9rjTjf0CrsxibpA>
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: Wed, 13 Jan 2016 11:44:33 -0000

On Tuesday 12 January 2016 15:14:13 Dave Garrett wrote:
> On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote:
> > On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote:
> > > 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.> 
> > If this were the path forward (and I doubt that it is), I would very
> > much prefer Peter Gutman's evolutionary TLS 1.3.
> I was just chatting a bit off-list, and apparently I wasn't aware of
> QUIC's latest plans, so it's not as clear as I previously said.
> Unfortunately, it seems that they have yet to actually write anything
> down (a too frequent pattern with QUIC), so I can't really comment on
> what I'd like to see happen in this realm anymore.
> 
> In any case, ~whatever~ comes after TLS 1.3 will hopefully have some
> major changes. I have no idea what that will be, but TLS 1.3 comes
> first. That's a discussion for a future time.

I remember this one quote, not sure who is it attributed to, but it goes 
something like this:

"I don't know what will replace Ethernet, but I'm sure it also will be 
called Ethernet"

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic