[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [66.196.116.98]) 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@96.231.127.62 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 2.0.0.24 (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 reasonable): 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. spt
- Re: [TLS] Proliferation of TLS cipher suites Bill Frantz
- [TLS] Proliferation of TLS cipher suites Sean Turner
- Re: [TLS] Proliferation of TLS cipher suites Peter Saint-Andre
- Re: [TLS] Proliferation of TLS cipher suites Nikos Mavrogiannopoulos
- Re: [TLS] Proliferation of TLS cipher suites Nicolas Williams