Re: [TLS] draft-sheffer-tls-bcp: DH recommendations (Martin Rex) Mon, 23 September 2013 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2144C21F86B2 for <>; Mon, 23 Sep 2013 09:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.455
X-Spam-Status: No, score=-9.455 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 225mVgWNZpCJ for <>; Mon, 23 Sep 2013 09:22:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC26E21F9EAD for <>; Mon, 23 Sep 2013 09:22:24 -0700 (PDT)
Received: from by (26) with ESMTP id r8NGML9H027622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Sep 2013 18:22:21 +0200 (MEST)
In-Reply-To: <>
To: Yaron Sheffer <>
Date: Mon, 23 Sep 2013 18:22:21 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: TLS Mailing List <>
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: Mon, 23 Sep 2013 16:22:38 -0000

Yaron Sheffer wrote:
> But new extensions are out of scope for draft-sheffer-tls-bcp. We need a 
> set of best common practices that people can actually deploy within the 
> coming year, hopefully earlier.

Personally, I believe that the cipher suites currently listed
in the document are *FAR* from realistic.

They're based on _several_ flawed assumptions:
  1) that optional EC crypto is available in deployed implementations
  2) that optional TLSv1.2 is available in deployed implementations
  3) that optional AES-GCM is available in deployed implementations
  4) that TLS clients universally have re-connect fallbacks to
     cope with TLS servers that are TLSv1.2-intolerant.

For a huge number of communication scenarios, all 4 of this list
apply only to one side, for a non-marginal, all 4 of this apply
to neither side.

Please do not underestimate problem (4).  There are currently
SSL accellerators sold (and widely used) that are limited to
TLSv1.0 and will abort connections when ClientHello contains
TLSv1.1 or TLSv1.2.  This year, the fiscal authority of Portugal (IRS)
launched Web-Services scenarios, where such TLSv1.2-intolerant
SSL Accelerators are being used in production.

What I really would appreciate is a recommendation that works
in the real world, providing a path forward that is realistic
to get added through a software update to *EXISTING* implementations,
which clearly rules out all 4 on the above list.