Re: [TLS] Another IRINA bug in TLS

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 21 May 2015 11:51 UTC

Return-Path: <nmav@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 63A9B1AD0C0 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 04:51:50 -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 XiwDtiKlHyXl for <tls@ietfa.amsl.com>; Thu, 21 May 2015 04:51:48 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08101AD0BF for <tls@ietf.org>; Thu, 21 May 2015 04:51:48 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 6D599A10D2; Thu, 21 May 2015 11:51:48 +0000 (UTC)
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBpjCf030245 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:51:47 -0400
Message-ID: <1432209104.3243.65.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Date: Thu, 21 May 2015 13:51:44 +0200
In-Reply-To: <555DC498.2000109@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> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QFKKB_eqPIB6TbQ03Hrmi5mbmAg>
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:51:50 -0000

On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote:
> On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote:
> 
> > Deprecating non-safe DH primes and having clients test primality of p and (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors.
> 
> I need something which prevents MITM attacks and can be applied as a
> software update without configuration changes, and without extensive
> testing because it is relatively risk-free.

Well, you assume that the so-called "safe primes" are universally used,
which is not really the case. Expecting all servers sending these
parameters wouldn't really work. In addition the check you have isn't
complete, you'll also need to calculate the order of the generator and
verify it is sufficient. I don't think that approach is close to being
reasonable to be done on every connection.

> Rejecting handshakes in clients without additional measures risks that
> (a) additional handshakes fail, leading to service outages and (b)
> clients will fall back no encryption at all (after manual intervention,
> or automatically in case of SMTP with STARTTLS and opportunistic
> encryption).

The way I tackled the issue in gnutls is to prioritize the ciphersuites
of the client in that order: ECDHE, RSA, DHE, and perform a size check
on the DHE ones.

regards,
Nikos