Re: [TLS] Another IRINA bug in TLS

Jeffrey Walton <noloader@gmail.com> Fri, 22 May 2015 17:05 UTC

Return-Path: <noloader@gmail.com>
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 8716E1A01E2 for <tls@ietfa.amsl.com>; Fri, 22 May 2015 10:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt7AJ6qjNMGY for <tls@ietfa.amsl.com>; Fri, 22 May 2015 10:05:32 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45EE1A6EE9 for <tls@ietf.org>; Fri, 22 May 2015 10:05:31 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so40559881igb.1 for <tls@ietf.org>; Fri, 22 May 2015 10:05:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.42.176.8 with SMTP id bc8mr10588389icb.22.1432314331382; Fri, 22 May 2015 10:05:31 -0700 (PDT)
Received: by 10.36.77.15 with HTTP; Fri, 22 May 2015 10:05:31 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>
Date: Fri, 22 May 2015 13:05:31 -0400
Message-ID: <CAH8yC8=F3jJgEzFQSN=ZMvoC4zunAsfHPs1k2km9dvFJ0bvg2g@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sYv9RH6mvRss3k3IwfvMcPFHWV0>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Another IRINA bug in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
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 17:05:34 -0000

On Fri, May 22, 2015 at 10:54 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> 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?

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.

Jeff