Re: [TLS] Cipher suite values to indicate TLS capability

Geoffrey Keating <geoffk@geoffk.org> Wed, 06 June 2012 00:06 UTC

Return-Path: <geoffk@geoffk.org>
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 87A6A21F85BB for <tls@ietfa.amsl.com>; Tue, 5 Jun 2012 17:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599]
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 1gZ+iZPh7VRI for <tls@ietfa.amsl.com>; Tue, 5 Jun 2012 17:06:59 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 30AEC21F8596 for <tls@ietf.org>; Tue, 5 Jun 2012 17:06:59 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id A867033D077; Wed, 6 Jun 2012 00:06:56 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Adam Langley <agl@google.com>
References: <CAL9PXLwdQctUub5oPx0tepsfveDo0bNKGBUaUBBFeq4u4D0BbA@mail.gmail.com> <m2sje9xsc0.fsf@localhost.localdomain> <CAL9PXLy_Lr+-ehOKSddtooVBpgUzxCyLKhWghC7UtOAt3HH2Rw@mail.gmail.com> <m2oboxxr5z.fsf@localhost.localdomain> <CAL9PXLx4qdv1AYv7f47=1f8j7UkkOuaYEn9PHeLnQRWkJ5NKDQ@mail.gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Tue, 05 Jun 2012 17:06:56 -0700
In-Reply-To: <CAL9PXLx4qdv1AYv7f47=1f8j7UkkOuaYEn9PHeLnQRWkJ5NKDQ@mail.gmail.com>
Message-ID: <m2ipf5xpzz.fsf@localhost.localdomain>
Lines: 21
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] Cipher suite values to indicate TLS capability
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: Wed, 06 Jun 2012 00:06:59 -0000

Adam Langley <agl@google.com> writes:

> On Tue, Jun 5, 2012 at 7:41 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
> > Why would you need to send the extensions?  (The RFC says they're
> > optional.)
> 
> Well, we could cross our fingers and hope that the server picks
> something acceptable I guess (or simply define the set of acceptable
> values for SSLv3). But extending SSLv3 to support ECDHE seems rather
> specific:

I think I'll go out on a limb and say that there are not any
SSLv3-only servers which actually support ECDHE, so if you fall back
to SSLv3 and yet ECDHE gets picked, you're under a downgrade attack
and the appropriate thing is to close that connection (and fall back
up, or whatever).  It doesn't matter what the server picks for the
parameters, you'd never want to use them.

Likewise there are probably not any SSLv3-only clients which support
ECDHE, so if you're a server and you get such a request, you can
probably close that connection too.