Re: [TLS] Another IRINA bug in TLS

Jeffrey Walton <> Fri, 22 May 2015 17:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8716E1A01E2 for <>; Fri, 22 May 2015 10:05:34 -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 Tt7AJ6qjNMGY for <>; Fri, 22 May 2015 10:05:32 -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 D45EE1A6EE9 for <>; Fri, 22 May 2015 10:05:31 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so40559881igb.1 for <>; Fri, 22 May 2015 10:05:31 -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=rPO+lreq1XySYE9r0DP3By3gcmPgehhUZLRri1aF1gY=; b=lqSYe7V+RnwAODY4hY9OyWdEN4UeMC7ZqZK3/uKWJCJLxDD97EuNZeJjVf2MhRErsK cpgwr8lXKEe4uyMri7NF8P4vQKd5DBooA5O0jORjWbxnQ9YZtKgdIs9hffEsp7iJuwy4 TlQuUDqW2jI3GUsOW9X7+lbeKJBtcq9CEzg3cUtDfIwIIAX04MdCudggoTRN+8Txh0mv gXVSMx1hWJXfA2ZkchGBPl/RtDqz3xQEdFboMDmkeNQ+YwYSNhg4Nz2Wm1JXtwFOxZQ+ dU9GTkqxcCxwEfno7ZD+OHrslMj8M8uhr4W72n1VS21//0fyEP8gkU7zXKrG4YeQK+p9 w4nA==
MIME-Version: 1.0
X-Received: by with SMTP id bc8mr10588389icb.22.1432314331382; Fri, 22 May 2015 10:05:31 -0700 (PDT)
Received: by with HTTP; Fri, 22 May 2015 10:05:31 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 22 May 2015 13:05:31 -0400
Message-ID: <>
From: Jeffrey Walton <>
To: Peter Gutmann <>
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: Fri, 22 May 2015 17:05:34 -0000

On Fri, May 22, 2015 at 10:54 AM, Peter Gutmann
<> wrote:
> Santiago Zanella-Beguelin <> writes:
>>Regarding validation of DHE parameters and how reasonable it is in practice,
>>I wanted to make some publicity for miTLS (
>>A miTLS client maintains a table of known trusted parameters, including the
>>subgroup order for parameters with non-safe primes. When receiving unknown
>>parameters from a server, it tests the primality of p and (p-1)/2 to check if
>>p is a safe prime (and caches a positive result in the table).
> So you do a full primality test (Miller-Rabin or whatever) for each connect?
> Doesn't that make it awfully slow?

The software under my purview does.

I don't allow the developers to use any parameters without validation.
That includes crypto parameters. But its for a systems that handles
medium and high value data; and not low value data where web browsers
and their use of TLS would be appropriate.

I don't think browsers will ever be able to handle anything other than
low value data, so I probably won't have to worry about web browsers
and what do (or don't) validate before use.

>>If the modulus is prime but not safe, miTLS checks if it is in the table of
>>trusted parameters and otherwise rejects it. We distribute miTLS with a pre-
>>populated table of parameters which we tested thoroughly (and we welcome
>>people to test further). Most of the time we hit an entry in the table.
> What testing do you do on unsafe primes?

GnuTLS with its Lim-Lee primes causes me a lot of problems because
they cannot be validated.

If we encounter them, then developers are *not* allowed to apply a
secret to them. The user has to generate a new, verifiable key and
then add that key to their keyring.