Re: [TLS] Another IRINA bug in TLS

Peter Gutmann <> Fri, 22 May 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9199D1A070E for <>; Fri, 22 May 2015 07:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6S2HLpjCgwoe for <>; Fri, 22 May 2015 07:54:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0A411A039D for <>; Fri, 22 May 2015 07:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1432306498; x=1463842498; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=YzdvMPqOh0zXT50Enw4tP0+OS/0+FW3XCSZUt9ky3ik=; b=HuUWYIIg82GLUzfq3kJoFrS6sgAq59FtdqFtDM0Kg186K/1ckG8xHd7L waPKbnGewK3BiI2woRX1BC2gnYEL7HsjX0Dz0TMH8Pgl70+9UwolHZGD7 2qUlviCZ6IU2vKrhpXrJG65pn8ClRBoeV9UmFqtkDzhch6HmnHvaawMAY oKtC6HcgmdlX2n9LvaUAJahup5jAr6FLc+JxD10yR3F8WRn3AlzjToIMa YsgHhAy2WnP3A2rMk8WxfhV9JPtOP8mXuOy9G9RYsSKqVGRDJzvFjp2fL EhCvuKCyM7+Qen7tlcq99Eg0mrRzeIag+LeX9HA1XuOLtuxv8tgcqZDVg Q==;
X-IronPort-AV: E=Sophos;i="5.13,475,1427713200"; d="scan'208";a="17643881"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 23 May 2015 02:54:54 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sat, 23 May 2015 02:54:54 +1200
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8A==
Date: Fri, 22 May 2015 14:54:53 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
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 14:55:00 -0000

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?

>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?