Re: [TLS] Consensus Call for acceptance of

Geoffrey Keating <geoffk@geoffk.org> Wed, 25 June 2014 20:13 UTC

Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562BB1A00BE for <tls@ietfa.amsl.com>; Wed, 25 Jun 2014 13:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvwmP4kPeSqZ for <tls@ietfa.amsl.com>; Wed, 25 Jun 2014 13:13:15 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2AE1A00D3 for <tls@ietf.org>; Wed, 25 Jun 2014 13:13:15 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 70A9E33D0DF; Wed, 25 Jun 2014 20:13:14 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: "Salz, Rich" <rsalz@akamai.com>
References: <9A043F3CF02CD34C8E74AC1594475C738DECE365@uxcn10-tdc06.UoA.auckland.ac.nz> <m2ha38vpa8.fsf@localhost.localdomain> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF0D0@USMBX1.msg.corp.akamai.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Wed, 25 Jun 2014 13:13:14 -0700
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF0D0@USMBX1.msg.corp.akamai.com>
Message-ID: <m2d2dwvjc5.fsf@localhost.localdomain>
Lines: 17
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VJo8tEXVNLHLiXSc7TMytOLE7gk
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Consensus Call for acceptance of
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Jun 2014 20:13:18 -0000

"Salz, Rich" <rsalz@akamai.com> writes:

> In our experience, the issue is legacy embedded devices and old
> Android phones, not XP.  And therefore, I'd be inclined to go with
> Peter's suggestion.

For Android, it's the same?  If your device is running some old
Android, like the 2.x versions, chances are this is because it can't
or won't be upgraded, ever, and the solution is to get a new device,
which comes with Android 4.x, which I believe has ECDH.

I don't know about general 'legacy embedded devices', but can you give
an example of one such device which does not support ECDH, will not
support ECDH, but is still being updated and for which the
manufacturer has indicated they might add this extension?  If there
aren't any, I would oppose this RFC as a needless complication to the
SSL protocol.