Re: [TLS] Another INRIA bug in TLS

Jeffrey Walton <> Fri, 22 May 2015 22:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D38F31A898A for <>; Fri, 22 May 2015 15:37:56 -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 vVsLJwzgNrEt for <>; Fri, 22 May 2015 15:37:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 156FB1A896A for <>; Fri, 22 May 2015 15:37:55 -0700 (PDT)
Received: by ieczm2 with SMTP id zm2so41112396iec.1 for <>; Fri, 22 May 2015 15:37:54 -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=3uKyOIHKKH0KvKcqiZP+DA2ZDB/GwBCQwGjh9kQudqg=; b=TFx27jXKZCB5g/uN2wmrWQ9RQ8LMbrBCHuA+pydxjxtKAx110VzcCeBuX4LTIGNxi7 5/9yjAIgQuyOCqgO4RPTGHJL92qYcTTkZXrrjOh+N/+6Os+tkC99dkKrpSpEp+DidHEC oJx3l305LFrE/hKy8b34QyM7n99rGR1bmD3BIlkrlZu7BUVDkAcE7gcC09jgkRYOiHFk Psh2f7KLKagmkmXMD5rN0OGUpyF7CgF7pFh8hgneW2KLYwkP0klh9Bs0BdcRFa2nIQOH tl7BVQcO42vjRqB0G1+igAhT7wV1tTtAVH9iNWskTw/NObLeICZrZ5NOUMkbzgzNaSRM EggQ==
MIME-Version: 1.0
X-Received: by with SMTP id wl14mr440869icb.36.1432334274633; Fri, 22 May 2015 15:37:54 -0700 (PDT)
Received: by with HTTP; Fri, 22 May 2015 15:37:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 22 May 2015 18:37:54 -0400
Message-ID: <>
From: Jeffrey Walton <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Another INRIA 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 22:37:57 -0000

On Fri, May 22, 2015 at 4:55 PM, Daniel Kahn Gillmor
<> wrote:
> [ i fixed typo in the Subject line because it bothered me; sorry if that
>   kills threading in anyone's MUA ]
> On Fri 2015-05-22 13:52:29 -0400, Santiago Zanella-Beguelin wrote:
>>>>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?
>> No. We do primality tests only if the prime isn't in the cache. That happens the
>> first time the client connects to a server, or when the server refreshes its
>> parameters. That, assuming the parameters aren't already in the pre-populated
>> cache.
>>>Doesn't that make it awfully slow?
>> No. The typical cost of validation is just one table lookup. This works
>> extremely well when people use just a few thousand parameters and don't change
>> them often. Even if that changes in light of Logjam (I hope it does!), online
>> primality tests for every connection are not prohibitive. I did a quick test
>> using Sage and the stock is_pseudoprime: testing if a 2048-bit prime is safe
>> takes ~180ms in a laptop, while computing two DH operations (exponentiations)
>> takes ~17ms. The amortized cost using a cache is of course much lower.
> I'm considering adding a Miller-Rabin primality check for the group
> modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section:
M-R is one check, but there are others. For example, trial division
and the choice of g in a group (g may not necessarily be a generator).

As a practical example from a guy who regularly validates all
parameters, see

What I found in the past that the IETF's choice of g = 2 meant that
various DH_param_check(...) would fail.