Re: [TLS] Another IRINA bug in TLS

Kurt Roeckx <kurt@roeckx.be> Fri, 22 May 2015 17:56 UTC

Return-Path: <kurt@roeckx.be>
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 E3BA61A87DB for <tls@ietfa.amsl.com>; Fri, 22 May 2015 10:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_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 6Id0orOXo5Eq for <tls@ietfa.amsl.com>; Fri, 22 May 2015 10:56:21 -0700 (PDT)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9ED11A87D0 for <tls@ietf.org>; Fri, 22 May 2015 10:56:21 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 3FEA11C20DF; Fri, 22 May 2015 19:56:19 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 1BCB71FE05FD; Fri, 22 May 2015 19:56:19 +0200 (CEST)
Date: Fri, 22 May 2015 19:56:19 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: Santiago Zanella-Beguelin <santiago@microsoft.com>
Message-ID: <20150522175618.GA10423@roeckx.be>
References: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1432219967072.32353@microsoft.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fYFOQvjEZB-ciErvtU6ZiW6fsl4>
Cc: Florian Weimer <fweimer@redhat.com>, "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
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:56:24 -0000

On Thu, May 21, 2015 at 02:52:47PM +0000, Santiago Zanella-Beguelin wrote:
> Regarding validation of DHE parameters and how reasonable it is in
> practice, I wanted to make some publicity for miTLS
> (http://www.mitls.org/).

I was unable to get it to build (using free software).

> 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). If the modulus is prime but not safe, miTLS
> checks if it is in the table of trusted parameters and otherwise
> rejects it.

When is it non-safe but trusted?

> 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. 
> 
> I think a table lookup per key exchange is about as reasonable as it
> gets.

I assume that's a table lookup in case it hasn't seen that prime
yet?  But I understand that they're recommending everybody to
generate their own prime.


Kurt