Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt

Sean Turner <turners@ieca.com> Tue, 17 September 2013 15:08 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAD711E8473 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.26
X-Spam-Level:
X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MwgRgybYccb for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:08:26 -0700 (PDT)
Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.216.19]) by ietfa.amsl.com (Postfix) with ESMTP id 86A8C11E8295 for <tls@ietf.org>; Tue, 17 Sep 2013 08:08:26 -0700 (PDT)
Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id DF27F242F876; Tue, 17 Sep 2013 10:08:25 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id A87DF242F782 for <tls@ietf.org>; Tue, 17 Sep 2013 10:08:25 -0500 (CDT)
Received: from [96.231.225.44] (port=55035 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1VLwt6-0003uL-Uz; Tue, 17 Sep 2013 10:08:25 -0500
Message-ID: <52387068.2050802@ieca.com>
Date: Tue, 17 Sep 2013 11:08:24 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com>
In-Reply-To: <522C3497.9020301@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [96.231.225.44]:55035
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Cc: tls@ietf.org
Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 17 Sep 2013 15:08:32 -0000

On 9/8/13 4:25 AM, Yaron Sheffer wrote:
> This is an early version of my proposal for a BCP-like document, to
> inform the industry on what can be done with existing implementations,
> while TLS 1.3 is still not ready.
>
> I would appreciate your comments of course. Specifically,
> I would like to fill in the Implementation Status table (Sec. 5) and
> would be glad to receive solid information (dates, planned dates,
> version numbers) from implementers.
>
> Thanks,
>      Yaron

Yaron,

Thanks for this draft, I'm supportive of it, and hope that the WG adopts 
it.  They've not had a history of adopting algorithm drafts, but this is 
one I think they should strongly consider adopting especially because it 
impacts the base specification.

A couple of things come to mind:

1. TLS isn't just used by browsers, but Brian Smith is also proposing 
some changes to the cipher suites offered by browsers 
(https://briansmith.org/browser-ciphersuites-01.html).  It'd be good to 
review those recommendations especially since he's recommending a few 
TLS_ECDHE suites ahead of TLS_DHE suites (assuming I'm reading the 
recommendation properly).  Also note that there's some information about 
implementation support there as well.

2. An implication of your draft is that version TLS 1.2 is preferred 
over other TLS versions.  That is kind of already done with the 
obsoletes trail from 1.0 to 1.1 to 1.2, but maybe it's time to dust off 
the issue of whether it's worth providing guidance on SHOULD NOT use SSL 
3.0/ TLS version 1.0/1.1.  Two caveats: 1) Unsure if it is practical to 
knock off older versions based on an algorithm recommendation given the 
deployment numbers, and 2) I'm also not sure this kind of recommendation 
needs to go in this draft.

3. (not specific to the draft) Going forward for TLS 1.3 maybe we should 
consider splitting out the MTI algorithms from the base specification so 
that we can update the MTIs on a regular basis without having to revise 
the base specification, which is what IPsec, S/MIME, PKIX, etc. have done.

4. I like Stephen's idea of explaining why PFS is needed.  Note that 
there's some information in RFC 4949 about PFS that you could start from.

5. Providing BCP algorithms for earlier TLS versions is okay in my mind 
essentially because those versions are still out there.

6. I'm torn on the idea of adding an appendix on how to 
add/remove/configure algorithms.  If it's information that's not readily 
available then I'd say it'd be worth documenting, but whether it goes in 
this draft or another I'd leave to the authors/wg.  (i.e., not sure we'd 
need to have a death match over the commands to input to apache to get 
this draft done)

On the procedural notes:

1. Don't worry about whether the draft's intended status is BCP or 
standards track.  I'd have no problem sponsoring it regardless; I've 
been down this path before, BCPs can document what is being done already 
or what we want to done now and in the future.

2. Feel free to use 2119 language, but depending on how you write it it 
might not be necessary.

spt