Re: [TLS] Another IRINA bug in TLS

Florian Weimer <fweimer@redhat.com> Thu, 21 May 2015 11:20 UTC

Return-Path: <fweimer@redhat.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 A6CCE1ACDE5 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 04:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 XpuWA0dkKC2c for <tls@ietfa.amsl.com>; Thu, 21 May 2015 04:20:34 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 61C821ACDD0 for <tls@ietf.org>; Thu, 21 May 2015 04:20:34 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBKXfB030499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tls@ietf.org>; Thu, 21 May 2015 07:20:34 -0400
Received: from oldenburg.str.redhat.com (ovpn-204-20.brq.redhat.com [10.40.204.20]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBKVVB023844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:20:33 -0400
Message-ID: <555DBF7E.9050807@redhat.com>
Date: Thu, 21 May 2015 13:20:30 +0200
From: Florian Weimer <fweimer@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
References: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com> , <1432134170.2926.9.camel@redhat.com> <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>
In-Reply-To: <1432206909.3243.45.camel@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/n5I5xqMnuKZPoLiT3eFFB0vJ9pU>
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
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: Thu, 21 May 2015 11:20:35 -0000

On 05/21/2015 01:15 PM, Nikos Mavrogiannopoulos wrote:

>> Interesting.  But do we want to encourage the use of additional magic
>> primes?
> 
> We do the same with elliptic curves.

I think the situation with curves is markedly different because
individual curves can have quite different properties.  With safe DH
primes of similar size, one is presumably as good as the other.

> We agreed on some groups and use
> these for simplicity. With arbitrary groups, a client cannot verify the
> quality of the parameters of the provided group by the server.

It could still run a primality check on (p - 1) / 2.

> It can only check its size which is an insufficient test if a client wants to
> enforce a particular security level.

On the other hand, a broken server might leak key material by other
means, and if that happens, there is nothing a client can do about that.

>>> However, that would not solve the incompatibility issue with old
>>> servers.
>> You mean, if the client rejects handshakes with defective primes, it
>> will not be able to connect to servers which use them?
> 
> The use case that will fail, is if there is a server which is configured
> to prefer DHE ciphersuites, and is setup with 512-bit primes, then no
> client will be able to connect to it, unless it disables DHE.

Yes, this is a tough scenario to solve.

-- 
Florian Weimer / Red Hat Product Security