[TLS] TLS 1.3 process

Sean Turner <TurnerS@ieca.com> Thu, 27 March 2014 21:48 UTC

Return-Path: <TurnerS@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 98A781A06A8 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 14:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GYczCBbxGD9A for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 14:48:55 -0700 (PDT)
Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com []) by ietfa.amsl.com (Postfix) with ESMTP id 67B3C1A06E1 for <tls@ietf.org>; Thu, 27 Mar 2014 14:48:55 -0700 (PDT)
Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 7BFA3FF0D60C9; Thu, 27 Mar 2014 16:48:53 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com []) by gateway07.websitewelcome.com (Postfix) with ESMTP id 567AAFF0D6061 for <tls@ietf.org>; Thu, 27 Mar 2014 16:48:53 -0500 (CDT)
Received: from [] (port=52401 helo=[]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <TurnerS@ieca.com>) id 1WTIAO-0005Ux-Qf for tls@ietf.org; Thu, 27 Mar 2014 16:48:52 -0500
From: Sean Turner <TurnerS@ieca.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <AF370E26-CA97-4CE3-9CC7-2F0939FE2B71@ieca.com>
Date: Thu, 27 Mar 2014 17:48:47 -0400
To: "<tls@ietf.org>" <tls@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-Sender: ([]) []:52401
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 10
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rTlVyrn2Rdf4yEf9cn8OH77x1Dw
Subject: [TLS] TLS 1.3 process
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: <http://www.ietf.org/mail-archive/web/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: Thu, 27 Mar 2014 21:48:58 -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." 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.

With this in mind and regard to the bigger question about the
process, here's how the chairs intend to proceed:

1. Start with the existing TLS document. As usual in IETF, this
   doesn't mean that any particular piece of the document cannot
   be changed if the WG wants to, but it's where we will start;
   it also makes it a lot easier to get through the process
   since the IESG, directorates, and WGs that depend on TLS 
   can see what changed.
2. If possible, remove the pieces we agree we don't need (hence the
   recent consensus calls).
3. Settle on the high-level handshake flows (charter items #1 and #2)
   in light of #2.
4. Reevaluate the handshake PDUs (charter item #4)
5. Update record protection mechanisms in the record layer
   (charter items #3 and #5)
6. Iterate on the document until complete. Key to this process is
   getting input from academic cryptographers, which is why we
   are prioritizing the handshake flows, because they are probably
   the piece that needs the most analysis.
7. Publish.

With that said, the reason for the present consensus calls should be
clear, as they are intended to either remove pieces (#2) or resolve
requirements for the handshake (#3).

To sum up: We have a set of requirements, from the charter and
from the consensus calls we're having now.  Our chartered goal is
to meet those requirements with the minimum set of changes to TLS. 

TLS co-chairs

j & e & s