Re: [TLS] Killing Algorithms

"Peter Yee" <peter@akayla.com> Fri, 03 April 2015 01:12 UTC

Return-Path: <peter@akayla.com>
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 2B3441A8AAA for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 18:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 KZBatPDnSR1M for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 18:12:44 -0700 (PDT)
Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079CA1A8A9E for <tls@ietf.org>; Thu, 2 Apr 2015 18:12:43 -0700 (PDT)
Received: from spectre ([173.8.184.78]) by p3plsmtpa06-07.prod.phx3.secureserver.net with id BDCi1q0061huGat01DCijb; Thu, 02 Apr 2015 18:12:43 -0700
From: Peter Yee <peter@akayla.com>
To: 'Bill Frantz' <frantz@pwpconsult.com>, tls@ietf.org
References: <r422Ps-1075i-F8BE1282BAD64B8397E9DAE49D77123B@Williams-MacBook-Pro.local>
In-Reply-To: <r422Ps-1075i-F8BE1282BAD64B8397E9DAE49D77123B@Williams-MacBook-Pro.local>
Date: Thu, 02 Apr 2015 18:12:51 -0700
Message-ID: <005801d06dab$4edcc1f0$ec9645d0$@akayla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHskLZoBr1oJ1vV2//8VjKecJuha50CM1oA
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QS3btNFJW2LMwsaOrePvFdTSJn4>
Subject: Re: [TLS] Killing Algorithms
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: Fri, 03 Apr 2015 01:12:46 -0000

I don't think killing off algorithms has been a problem of not having a
means to do so.  Rather, I suspect it's a question of inertia.  It takes a
really catastrophic failure or wide news coverage of a new attack to move
server admins away from a configuration that "has been working fine up until
now."  Breaking someone's fielded server setup with a special message is not
going to be a popular feature.  Enterprises are a conservative lot when it
comes to changing things.

		-Peter

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Bill Frantz
Sent: Thursday, April 02, 2015 5:38 PM
To: tls@ietf.org
Subject: [TLS] Killing Algorithms

There has been discussion stating that having at least two 
algorithms for each function allows algorithms to be turned off 
when weaknesses are discovered. There needs to be a way to 
actually implement this decision.

At a minimum, the security considerations section should mention 
this requirement. Perhaps saying something like this:

History has shown that all of the algorithms SSL/TLS depended on 
20 years ago have been shown to have weaknesses and as a result, 
they are no longer included in TLS 1.3. There is no reason to 
believe that the algorithms required for TLS 1.3 won't share 
their fate. TLS 1.3 requires at least 2 algorithms for each 
security function so failing algorithms can be turned off. Each 
implementation of TLS MUST have a technique for effectively 
turning algorithms off.

-----------

 From my point of view, acceptable techniques include online 
code update and special messages which cause implementations to 
permanently cease using an algorithm, along with methods and 
procedures to ensure that these techniques actually work in the field.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 
Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum    | Los Gatos, 
CA 95032

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls