Re: [TLS] Another IRINA bug in TLS

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 01 June 2015 21:20 UTC

Return-Path: <dkg@fifthhorseman.net>
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 78B3C1A0013 for <tls@ietfa.amsl.com>; Mon, 1 Jun 2015 14:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 0t6v00svVaH6 for <tls@ietfa.amsl.com>; Mon, 1 Jun 2015 14:20:40 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 074BA1A000E for <tls@ietf.org>; Mon, 1 Jun 2015 14:20:39 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A8AB8F984; Mon, 1 Jun 2015 17:20:36 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 861331FF5D; Mon, 1 Jun 2015 17:20:14 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "noloader\@gmail.com" <noloader@gmail.com>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <CAH8yC8=F3jJgEzFQSN=ZMvoC4zunAsfHPs1k2km9dvFJ0bvg2g@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz>
User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Mon, 01 Jun 2015 17:20:14 -0400
Message-ID: <87k2vncei9.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ABmUJsEOSsJ6nZGtdwH8zQHdZE0>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Another IRINA bug in TLS
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: Mon, 01 Jun 2015 21:20:41 -0000

On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote:
> Jeffrey Walton <noloader@gmail.com>; writes:
>
>>GnuTLS with its Lim-Lee primes causes me a lot of problems because they
>>cannot be validated.
>
> Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as well!), it's
> the fact that TLS uses the PKCS #3 format rather than the DSA format, so
> you've got nice verifiable values for which you have to throw away the
> parameter used to verify them and send them in an unverifiable format.  Having
> said that, there's a pretty simple fix, define an extension that acts like the
> existing propose/accept extensions that signals a change in DH values to the
> DSA form (p, q, g) rather than PKCS #3 form (p, g).  And for TLS 1.3, use the
> DSA form by default, not the PKCS #3 form.

If we're still shipping arbitrary groups across the wire, then adding
(q) to the data over the wire not only increases the size of the
handshake (by the size of q) but now the receiving peer has to verify
that:

 (a) p is prime

 (b) q itself is prime

 (c) p is actually a Lim-Lee prime

either that, or they can skip the checks and cross their fingers.

Standardizing on known safe prime moduli seems simpler and easier and
less likely to include some steps that people will be tempted to skip
for speed.

        --dkg