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

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 17 September 2013 19:10 UTC

Return-Path: <yaronf.ietf@gmail.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 89AF111E82D5 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 12:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level:
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 xjmoAJIoOVag for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 12:10:09 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5916111E82CD for <tls@ietf.org>; Tue, 17 Sep 2013 12:10:09 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hn9so5430254wib.5 for <tls@ietf.org>; Tue, 17 Sep 2013 12:10:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DX7Wyh9dDtOfGX3DVvcXB1nQU44Ilx68RxEcteMsAY8=; b=Tauhb2vvvenqtGVe2fotoXa7NU6CIQr4pcdS9tFs2GyKHeNQV/PTabYDQJ1LZDZBhP TVQHAy/TfCTHF0Y9/8A7oD6vYzhCREEzqk26aRJW5jSVPycu2yjfpj+iFPVwuVhANZsX VgEEiEYV7nMKt2nACGtKTi5KBrnUZv+62XnxIQbWL0QO+AyfZbcG2XepROD5Q6prTsHm jj6EY21UGGxNLLIO//VAFZX6VUq6PhmTRAciAeKKZYAXlXypAHXH6Z2udWgRC3jJqbcP vGmxBHXRuwwBVg1rntJflfrr3Um48X/C65QgQaYFLW33x+6p2Vh9B9kmxJD3aPZVvloK TC+g==
X-Received: by 10.180.39.242 with SMTP id s18mr3675048wik.47.1379445008406; Tue, 17 Sep 2013 12:10:08 -0700 (PDT)
Received: from [10.0.0.8] (bzq-79-181-188-99.red.bezeqint.net. [79.181.188.99]) by mx.google.com with ESMTPSA id fz8sm6593445wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 12:10:08 -0700 (PDT)
Message-ID: <5238A90E.5090100@gmail.com>
Date: Tue, 17 Sep 2013 22:10:06 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Sean Turner <turners@ieca.com>
References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> <52387068.2050802@ieca.com>
In-Reply-To: <52387068.2050802@ieca.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 19:10:10 -0000

Hi Sean,

Thanks for your review. Please see my comments below.

	Yaron

On 09/17/2013 06:08 PM, Sean Turner wrote:
> On 9/8/13 4:25 AM, Yaron Sheffer wrote:
[...]
>
> 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.

Thanks for pointing it out. It is very useful. And it agrees on the #1 
cipher suite with our upcoming -01 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).

>
> 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.

TLS 1.2 is sort-of implicit in the draft. Also, there have been 
proposals to backport GCM to 1.0 and 1.1. I'm not sure if it makes sense 
(vs. wholesale transition to 1.2), but if that happens, fine.

>
> 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.
>

I agree.
> 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.
>

Ralph contributed excellent text on PFS for -01.

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

Except that nobody wants to come forward with a proposal for such 
algorithms, because so much is unfortunately broken. E.g. I don't think 
you can recommend AES-CBC without some of the mitigations people have 
implemented.

>
> 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)

I simply don't have the time to do it. But here's someone who did: 
http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

>
> On the procedural notes:

Let's go into this when we discuss WG adoption. Currently the draft is 
strictly lower case.

>
> 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