Re: [TLS] TLS 1.3 process

Trevor Perrin <> Thu, 27 March 2014 22:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BC60D1A024E for <>; Thu, 27 Mar 2014 15:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ozGveRcyy4fu for <>; Thu, 27 Mar 2014 15:45:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5B9C1A06F0 for <>; Thu, 27 Mar 2014 15:45:57 -0700 (PDT)
Received: by with SMTP id fp1so3997941pdb.28 for <>; Thu, 27 Mar 2014 15:45:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZxKhvEk4If5Vnu2MuIdbJgBVoe7hjlUP/CuBrI2+/+c=; b=PF0JPwEfGVkYQocXkBHVdvnQ/y8fJZIwY2Clgbna7NHxy5Hqn8lEGtG6YLlhpTcC/5 tCUtiGrrnKkF1U2aK/luLfkLvLFiLTV1wXlQJbgECnNXwAwx4DL5VJi3T2M9qwMO42Fa QEYsEVTqAcs7znhV7tJpymSLsQW1wpHSCPadBmR/SYd5OyMlkhzHcQC3ktEAaJV7FvbK 01/PA3Qy7rhCZH0BywQ6KFIfCwLfAly8aW3tsHNPKzWLDkk+JFJYT0RqVPjUZdCAbrwD klWSCr8EDqof8a+CHyV46JlKhy8KfVyOkU5yu6ktuxVSlr5MwPVskVyuwmeJEelJZngh zTUg==
X-Gm-Message-State: ALoCoQljBv7o1VNJ6j6voy5xp8/RhaYj4OWbvlpKw91T+60/P0lTeuxsTeXLgLnoBNcvf0i0hcLl
MIME-Version: 1.0
X-Received: by with SMTP id hh2mr4536463pac.150.1395960356145; Thu, 27 Mar 2014 15:45:56 -0700 (PDT)
Received: by with HTTP; Thu, 27 Mar 2014 15:45:56 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
Date: Thu, 27 Mar 2014 15:45:56 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Sean Turner <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "<>" <>
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: Thu, 27 Mar 2014 22:46:00 -0000

On Thu, Mar 27, 2014 at 2:48 PM, Sean Turner <> wrote:
> All,
> 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." This
> is not to say that we can't consider new cryptographic handshake flows
> -- TLS has always been open to that -- but completely replacing TLS
> with a new protocol is out of scope for this WG.

Hi Sean,

Thanks for creating this discussion.

The distinction between a "new protocol" (forbidden!) and
re-evaluating / updating both the handshake and record layer is not
super clear to me.

For example: Eric's draft redesigns the TLS handshake around the new
concept of "semi-static public keys".  That gave me the impression
we're willing to consider radical changes!  Is that not the case?

I also didn't expect such a strict interpretation of the charter, and
such a rigid process.  Your email in January gave a different


A couple of people have mentioned the fact that list of objectives is
incomplete or they're worried their issue not being listed means it's
out of scope.  Right now the charter includes the following to address
this (at least in my mind) "Some of the main design goals are as
follows, in no particular order:"  That list is honestly there to make
sure the IESG will be comfortable agreeing to the rechartering.  What
I hope will happen is that folks can bring their proposals, they get
evaluated, and the WG will use its better judgement about what makes
sense to get adopted.

That email made it seem like we should not worry too much about the
charter, we'd have time for "folks to bring their proposals" later.

I would have asked for more clarity on the charter - and the
"minimizing gratuitous changes" phrase - if not for that.

Anyways, maybe this is just me.  If everyone else understand what
scope of changes is allowed, and is happy with the step-wise process
you describe, then that's fine.  I'm happy we're discussing this.

But I would personally prefer a more open process based around
soliciting and comparing different proposals, without pre-judging in
advance what changes are "gratuitous".