Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Bill Frantz <> Wed, 18 September 2013 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39CAB11E810A for <>; Wed, 18 Sep 2013 14:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.369
X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OLPMVlL52Mm7 for <>; Wed, 18 Sep 2013 14:10:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 320F811E810B for <>; Wed, 18 Sep 2013 14:10:53 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by with esmtpa (Exim 4.67) (envelope-from <>) id 1VMP1O-0004LL-L6 for; Wed, 18 Sep 2013 17:10:50 -0400
Date: Wed, 18 Sep 2013 14:10:50 -0700
From: Bill Frantz <>
X-Priority: 3
In-Reply-To: <>
Message-ID: <r422Ps-1075i-2C2D7B0A418A4E33AF208E394FDB4A63@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec794c640c7c373eabf556b357cc1a4a4d8e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
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: Wed, 18 Sep 2013 21:10:59 -0000

On 9/18/13 at 11:46 AM, (Michael Ströder) wrote:

>First, I really appreciate that you write down this BCP document.
>But I wonder what the exact scope should be.
>In the abstract you say "existing standards and implementations", I guess to
>exclude approaches yet to be defined in a new standard. Agreed.
>But does that also exclude pushing implementors to slightly improve their
>software? The "deployers rather than for implementers" in the introduction
>sounds like it.
>If that's the scope you're stuck into recommending the least common
>denominator of today's implementations and implementors can take your RFC as
>excuse to stop improving their implementations.
>Also you're in the trap of choosing "widely-used" implementations for your
>"Implementation Status" section which is always questionable depending on
>personal deployments, especially since the main focus now seems to be web
>servers and browsers.
>Frankly I have no idea how to get out of this though.

I would address the issue of DHE keys that are limited to 1024 
bits by saying that the use of 1024 bits is the best current 
practical practice. I would also follow that recommendation with 
a note that 1024 bits is smaller than the best current practice, 
but is the limit provided by current implementations, so 
following the best current practice will change when 
implementors get off their butts.

A section in the document listing some of the implementations 
that can't perform to best current crypto practice and where 
they are deficient might also be a useful goad.

Cheers - Bill

Bill Frantz        | Re: Computer reliability, performance, and security:
408-356-8506       | The guy who *is* wearing a parachute is 
*not* the | first to reach the ground.  - Terence Kelly