[TLS] Killing Algorithms

Bill Frantz <frantz@pwpconsult.com> Fri, 03 April 2015 00:37 UTC

Return-Path: <frantz@pwpconsult.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D8B7C1A8996 for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 17:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JjXDd2WiEmj1 for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 17:37:56 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net []) by ietfa.amsl.com (Postfix) with ESMTP id 5111D1A8994 for <tls@ietf.org>; Thu, 2 Apr 2015 17:37:56 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1YdpcR-0004Vy-HL for tls@ietf.org; Thu, 02 Apr 2015 19:37:55 -0500
Date: Thu, 02 Apr 2015 17:37:50 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: tls@ietf.org
X-Priority: 3
Message-ID: <r422Ps-1075i-F8BE1282BAD64B8397E9DAE49D77123B@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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791ce8ce0d6e7ca1b1d77933f8a9f1a483350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7pusQ617CsgtFHGbJCF6uDCQ-tw>
Subject: [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 00:37:58 -0000

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