Re: [TLS] Deprecating more (DSA?)

Watson Ladd <watsonbladd@gmail.com> Thu, 17 April 2014 03:24 UTC

Return-Path: <watsonbladd@gmail.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 53A2F1A0024 for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 20:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 zHT96RosC_xH for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 20:24:48 -0700 (PDT)
Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB01A007B for <tls@ietf.org>; Wed, 16 Apr 2014 20:24:47 -0700 (PDT)
Received: by mail-yh0-f54.google.com with SMTP id f73so11660164yha.13 for <tls@ietf.org>; Wed, 16 Apr 2014 20:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1urbsak5N7KG9ETyCltIXQVISZipC3twMnOSPcNPpR8=; b=uovVT/y6EDJbOXIFGxpCkmszrSabHa7SBrZE/jp0WZiOzEI4W+vJV2dVawO5RGmL3V 7g5w8TMLbOghSwF2ag6yZz1QR+EoDHN9zAg/G+bFhShb5YZgIeFtinABPOlLyainAI/w 8+kNdtd+HzAPbPnUEVu1lpj8T6eepDdAAcYXjARvV1g9FsoqMG1+VmNmipgzWvED36Bc cvVfFFaVPqzKOj6Inz4eoHlRv7Iavyj4EWPf8ahooXV3wDSpEaKaweHnBSec2rajBEFH MC+aLhyuc8B1k6vbVjvjwFOnOLV0fa7tpaJ0wEjJt2IdvqoUoT/Szrht4DFTBRffhmEd Ibug==
MIME-Version: 1.0
X-Received: by 10.236.39.72 with SMTP id c48mr18458594yhb.89.1397705084419; Wed, 16 Apr 2014 20:24:44 -0700 (PDT)
Received: by 10.170.63.197 with HTTP; Wed, 16 Apr 2014 20:24:44 -0700 (PDT)
In-Reply-To: <C26BBD5C-C990-43B3-9466-9224897D2AD6@cisco.com>
References: <CABcZeBOvxL7Zws0UNowViBWGaVBgfm3zXt8=dNPKffGfN3q2gA@mail.gmail.com> <20140415153435.7f82b3a0@hboeck.de> <534F05DD.5010906@akr.io> <C26BBD5C-C990-43B3-9466-9224897D2AD6@cisco.com>
Date: Wed, 16 Apr 2014 20:24:44 -0700
Message-ID: <CACsn0ck+ViySVOBy6j+_Ug+gzqRqC2wJ3x8j1rnYBgrSyRrwqA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/refZRCOH8tjze-F6-qgWXm8c_t4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating more (DSA?)
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: Thu, 17 Apr 2014 03:24:49 -0000

Dear all,
I support most of the removal ideas. I would like to note in
particular that 3DES has a 64-bit block, which limits the transferable
data to 2^32 blocks, and so as a backup to AES it is painful. (We
would also need to fix the EtM problem with it: a lot of work that we
don't have to do). I think DHE will fall before ECDHE, but they are
similar enough

ECDSA is a complicated story. Yes, it makes unnecessary use of a
random number generator during signing. It is much safer to add 32
bytes to the secret key, hash that with the message, take that key,
stretch to twice as long as the group order with the hash function.
The inversion of k serves no purpose now that Schnorr's patent has
expired. It cannot be batched.

However, it is still very secure. I would like to see more performant
alternatives develop, but from a security perspective it's fine. FIPS
can do it however they can, and non-FIPS people will do it the right
way. I don't think removal is the right decision at this juncture.

Sincerely,
Watson Ladd