[TLS] Proliferation of TLS cipher suites

Sean Turner <turners@ieca.com> Thu, 24 June 2010 18:08 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 100453A6928 for <tls@core3.amsl.com>; Thu, 24 Jun 2010 11:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.642
X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id yJTdpY8yPEtj for <tls@core3.amsl.com>; Thu, 24 Jun 2010 11:08:50 -0700 (PDT)
Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com []) by core3.amsl.com (Postfix) with SMTP id BE34E3A6889 for <tls@ietf.org>; Thu, 24 Jun 2010 11:08:50 -0700 (PDT)
Received: (qmail 41037 invoked from network); 24 Jun 2010 18:08:56 -0000
Received: from thunderfish.local (turners@ with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 24 Jun 2010 11:08:56 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: RXietNIVM1mYvnthGkOR52en07ofq03vrRuXNvjBYe4zRwS gLmua66tIM6Fo2lp9fXmgoMnmXi2sM5bQK2SEIY62p4gvs.zy_7BYFfdZHID 5sQLouCc5ddrQcUslmAUhpBaJ7NLVnSgk1AeV5zroksEyYvhdqZNmIQMwmaD zYUywO48.QGO8jUhMCv.QaDdSzDDoiAt8JS2vXwVmtm0EHVyTurSNkSYwqWC MsqZoRl7RHWMxsui3FSSgExJiTCJg2c_y5aG4kwsRWclwQxD0qw53KYQdtls WvPnNBZ.v.YNoLKcAUwuhm8tMNx80cSdhvNu2ixm3Jkz6R.kHx.gD7QuYdny 24ob4KtPn7B7MLFZnthbGOVfQ8Cg_EXVoCWbf5Ikerkp90e3Omviw6YS3nIu h1ZIF5XTJjk1bEjqmJL7PBc1yLF8-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C239F37.3010400@ieca.com>
Date: Thu, 24 Jun 2010 14:08:55 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [TLS] Proliferation of TLS cipher suites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 24 Jun 2010 18:08:52 -0000

The TLS WG has had requests to adopt TLS cipher suites I-Ds.  If the 
WG declines (as it has recently), the authors then come to me.  What 
I'd like to layout is a plan for determining what route the I-Ds 
should take through the IETF standardization process.  Here's the 
steps I'm suggesting (I'd like to see if people think these are 

1) Submit an individual I-D documenting the TLS cipher suites
(document the cryptographic algorithm somewhere else).

2) Ask the TLS WG for adoption.  If the answer is no, then jump to #5.

3) Proceed as WG document.  WG selects and requests the track.

4) AD processes the document normally.  In general, this means
progressing on the requested track.  If the WG proposed standards
track, the AD will consider whether there is broad international
support for this algorithm. The AD may decide to request publication
as Informational if support is not broad-based.

5) Authors ask for AD sponsorship of I-D.

6) AD will ask the following question: Is there broad international
support for this algorithm.  If the answer is no, then jump to #8.

7) AD will sponsor the document for publication on standards track.

8) AD will sponsor the document on either informational or
experimental track.

I obviously think that almost all cipher suite I-Ds ought to end up
informational RFCs.  Too many standards track cipher suites leads to
implementation difficulties.  Additionally, the reviews in the WG
aren't on the cryptographic algorithm, it's just on whether the
document properly presents the cipher suites.  For non-standards track
TLS cipher suite assignment, there's an expert review that performs
this role. Regardless of the path followed, the expert reviewer still
has to do their job.  That's how the WG wanted it and we're going to
give it to them.

To summarize, we think there are two ways to get a standards track TLS
cipher suite RFC:

Rule 1 - If the I-D came from the TLS WG.

Rule 2 - If the cipher suite has broad international support.