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

Hanno Böck <> Tue, 10 September 2013 09:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80B2421F9CBD for <>; Tue, 10 Sep 2013 02:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U+72rzD6ccjZ for <>; Tue, 10 Sep 2013 02:47:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4930721E80DC for <>; Tue, 10 Sep 2013 02:47:38 -0700 (PDT)
Received: from localhost ( [::ffff:]) (AUTH: LOGIN, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by with ESMTPSA; Tue, 10 Sep 2013 11:47:28 +0200 id 00000000000000DE.00000000522EEAB0.00004E81
Date: Tue, 10 Sep 2013 11:47:18 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary=""
Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Sep 2013 09:47:44 -0000

On Sun, 08 Sep 2013 11:25:59 +0300
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.

I was asked on another list to cross-post my comments on it here:

I don't really see from the document why the authors discourage
ECDHE-suites and AES-256. Both should be okay and we end up with four

Also, DHE should only be considered secure with a large enough modulus
(>=2048 bit). Apache hard-fixes this to 1024 bit and it's not  
configurable. So there even can be made an argument that ECDHE is more
secure - it doesn't have a widely deployed webserver using it in an
insecure way.

Hanno Böck