IETF Logo Mail Archive

Re: [TLS] Another IRINA bug in TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 22 May 2015 14:55 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 9199D1A070E for <tls@ietfa.amsl.com>; Fri, 22 May 2015 07:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S2HLpjCgwoe for <tls@ietfa.amsl.com>; Fri, 22 May 2015 07:54:59 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A411A039D for <tls@ietf.org>; Fri, 22 May 2015 07:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; 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-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 May 2015 02:54:54 +1200
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sat, 23 May 2015 02:54:54 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8A==
Date: Fri, 22 May 2015 14:54:53 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/D2kkRNrEN_aPynqAruL3GZuO64U>
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: Fri, 22 May 2015 14:55:00 -0000

Santiago Zanella-Beguelin <santiago@microsoft.com> writes:

>Regarding validation of DHE parameters and how reasonable it is in practice,
>I wanted to make some publicity for miTLS (http://www.mitls.org/).
>
>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?

Peter.

v2.23.0 | Report a Bug | By Email