Re: [TLS] TLS 1.3 process

"Salz, Rich" <> Fri, 28 March 2014 14:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6A1AC1A0668 for <>; Fri, 28 Mar 2014 07:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KJNewJfGXvKD for <>; Fri, 28 Mar 2014 07:12:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 482A81A065A for <>; Fri, 28 Mar 2014 07:12:35 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id DBBB2480C8 for <>; Fri, 28 Mar 2014 14:12:32 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id CFB2C482E8 for <>; Fri, 28 Mar 2014 14:12:32 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 9F65947BD2 for <>; Fri, 28 Mar 2014 14:12:31 +0000 (GMT)
Received: from ([]) by ([]) with mapi; Fri, 28 Mar 2014 10:12:31 -0400
From: "Salz, Rich" <>
To: "<>" <>
Date: Fri, 28 Mar 2014 10:12:30 -0400
Thread-Topic: [TLS] TLS 1.3 process
Thread-Index: Ac9KBl4J0vN1MCo2RDuY6VdusdWJbgAh8Jww
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] TLS 1.3 process
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Mar 2014 14:12:40 -0000

> The TLS WG charter is pretty clear that the intention isn't to design a completely new protocol but rather to revise TLS,
> and specifically to "place a priority in minimizing gratuitous changes to TLS."


It seems to me that there are almost three viewpoints within this WG.  With the hope that I'm equally unfair to everyone, I'd summarize them like this:
	- Update to modern crypto knowledge to fix bugs, and some modern features and be done
	- Make big changes to fix serious problems
	- Start over from a clean sheet; "I don't know what it will be, but we'll call it TLS."

I put myself in the first group (except for SNI encryption, which will get a separate post :), could be convinced to support something from the second once it's written down, and am probably not qualified to evaluate anything from the third group (few people are). Interestingly, barring divine intervention, the above list is probably in order of length of time needed, as well. That would seem to indicate that there's room for all three efforts here.


Principal Security Engineer
Akamai Technology
Cambridge, MA