Re: [TLS] Another IRINA bug in TLS

Jeffrey Walton <> Mon, 01 June 2015 21:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 27D9D1A006F for <>; Mon, 1 Jun 2015 14:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bz3gz9WH5LVF for <>; Mon, 1 Jun 2015 14:34:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 409DA1A0063 for <>; Mon, 1 Jun 2015 14:34:01 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so72324934igb.1 for <>; Mon, 01 Jun 2015 14:34:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aXqvmzOxhLlnQsmBmFAj3oYQVSaja8lDMZggEx/metY=; b=0Pf9pNc9g69nOtXbeknZHb8M4J0hD519SSAhTrriYC7k4KNXSHZPSIU0Hk+hn9yk2e WlSsKpKxbiCl7Yz8G0Z57SxvM8eB7V7KDrf8YcBIbsyBRORpxDrQooJiwIEW03OuYkQN blVvB7PxCQzKnHuWSg0PMlGrqSJoC/glltfFAAkSPIvnN/jK5/Q47iBvRhdQQrFw/h2c lKGE6+bh40lnn+FhfXOqEf5fTC90qWQacN1XJW+Om0fuZ6azcpBfvRXULQFtFR9kJ3aD JnFlbPUCfQBT4DGamG1h7xLUjZCu4dsPPdFxnjcRLTg3GuYu1SN+qHuePP5sKxnlpjQe TRLQ==
MIME-Version: 1.0
X-Received: by with SMTP id u5mr16456346igh.9.1433194440793; Mon, 01 Jun 2015 14:34:00 -0700 (PDT)
Received: by with HTTP; Mon, 1 Jun 2015 14:34:00 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 1 Jun 2015 17:34:00 -0400
Message-ID: <>
From: Jeffrey Walton <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Another IRINA bug in TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jun 2015 21:34:03 -0000

On Mon, Jun 1, 2015 at 5:20 PM, Daniel Kahn Gillmor
<> wrote:
> On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote:
>> Jeffrey Walton <> 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.
Yeah, agreed.

The little voice in the back of my mind is saying the NSA would love
to see standard groups so they can build those big tables and store
them in Utah in its new data center with shiny new floors. But I'll
resist the urge (until Karthikeyan's next paper)....