Re: [TLS] TLS 1.3 process

Trevor Perrin <> Fri, 28 March 2014 16:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2ACBD1A0695 for <>; Fri, 28 Mar 2014 09:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3lDmy25L8-4z for <>; Fri, 28 Mar 2014 09:52:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F1CF91A0668 for <>; Fri, 28 Mar 2014 09:52:26 -0700 (PDT)
Received: by with SMTP id w61so2889923wes.1 for <>; Fri, 28 Mar 2014 09:52:24 -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=fLlSGuGZ/XrkQVnNGUkagnf3qkViqdW6S3EwvdKWtP8=; b=Qbn6tp73rnIa+ZYTkPnOX0C07uiWH0JJAfxfp+2kZrDBthc8dtd3VQP83LehCyTFcx 6cHPXkQpaAIj+mJMjqti48KQHPHRCQy8Zn1JZKKhzmSdRzDPz7pqNQNYK1tRuQmbiA3u 5RTpBRy2wBBUoKwLS/LDargjpkb1a9EhH57zWDUa6GkK2XcJojDah4pOSzwY5gD2z0O7 xpV6mZt7xEise1SGnYXv+8okuFOCnC8obFLRu3mDRdkE4wJjF9oa2hDOWNgFgL0kJLP0 Ug+Ii2wEKibf+vKWH3XFrF0mTeJCmimUUdMzww9oHX4XhOpbSh4ftAl0l5f7Jwwr5owL ieSQ==
X-Gm-Message-State: ALoCoQkV3ExbD9nY8AQQMXL9rfVML2nTVInJr+V0TDPRq0WM9DgWgpZpgox6YI4QRGUGiU7gVMIe
MIME-Version: 1.0
X-Received: by with SMTP id b3mr49173881wie.20.1396025544357; Fri, 28 Mar 2014 09:52:24 -0700 (PDT)
Received: by with HTTP; Fri, 28 Mar 2014 09:52:24 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 28 Mar 2014 09:52:24 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Eric Rescorla <>
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: Fri, 28 Mar 2014 16:52:29 -0000

On Fri, Mar 28, 2014 at 8:34 AM, Eric Rescorla <> wrote:
> On Fri, Mar 28, 2014 at 7:40 AM, Nikos Mavrogiannopoulos <>
> wrote:
>> On Fri, 2014-03-28 at 10:12 -0400, Salz, Rich wrote:
>> > > 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."
>> > +1.
>> >
>> > 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."
>> This is not my impression of the discussions and the meetings. Eric in
>> the last meetings has presented a list of changes to the protocol that
>> really exceeds the "Update to modern crypto knowledge to fix bugs, and
>> some modern features and be done", (whatever that means).
>> So my understanding is that there will be big changes (e.g., reducing
>> handshake messages, redesign of handshake to encrypt everything) to fix
>> serious and not serious problems (e.g., reducing the round-trips),
> Yes, I think the changes to the handshake we have been discussing
> probably would fall under #2 in Rich's taxonomy.

Agreed with Nikos and Eric that the WG (and charter) seemed willing to
consider major changes, as evidenced by the interest in Eric's "new
flows" draft.

If anything, I'm not sure the difference between Rich's #2 and #3
really exists - if we're willing to replace the existing TLS initial
and resumption flows with a flexible composition of exchanges based
around semi-static public keys, zero-RTT pre-emptive encryption, and
anti-replay tokens (Eric's draft) - and revisit the crypto - then
we're designing a new protocol, whether we admit it or not.

>> and
>> the question is whether to do it:
>> 1. within the working group (which is stated to have no crypto
>> expertise).
>> 2. by using external expertise.
> I actually don't think think this is the question, since IETF work is
> done in WGs and we would reach out (and are reaching out) for
> external expertise in any case.

Don't fully agree with Nikos.  For (1), this WG *does* have
participation from many cryptographers.  For (2), it's true anyone can

But Nikos has a point - there are differences in how processes
encourage or discourage participation.

I think creating a complex protocol by trying to reach consensus on a
hundred different points individually will result in a huge volume of
complicated, hard-to-follow discussions, which will need to be sorted
out at f2f meetings with substantial wrangling and steering from the

So the only people able to fully participate will be those willing to
invest hours a day deciphering mailing list threads and trying to
"win" discussions, and spend the time and money to attend IETF
meetings where the big decisions will be made.

In contrast, a process based around alternative proposals makes it
much easier to participate by either submitting a proposal or
reviewing others.  And the range of things being considered becomes
much more legible, since once can review a few leading proposals
instead of trying to reverse-engineer debates embedded in thousands of
mailing list posts.