Re: [TLS] Another IRINA bug in TLS

Florian Weimer <fweimer@redhat.com> Thu, 21 May 2015 11:42 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 146761ACE63 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 04:42:22 -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 2jg2v4gaFJVR for <tls@ietfa.amsl.com>; Thu, 21 May 2015 04:42:20 -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 D361E1ACE11 for <tls@ietf.org>; Thu, 21 May 2015 04:42:20 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBgKGK022785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 May 2015 07:42:20 -0400
Received: from oldenburg.str.redhat.com (ovpn-204-20.brq.redhat.com [10.40.204.20]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBgHaC026339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:42:19 -0400
Message-ID: <555DC498.2000109@redhat.com>
Date: Thu, 21 May 2015 13:42:16 +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: Santiago Zanella-Beguelin <santiago@microsoft.com>, 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>, <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com>
In-Reply-To: <1432207863352.27057@microsoft.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7HMTJVHczDwFDzQn6YkeMZV5V70>
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:42:22 -0000

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.

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).

I'm not sure if it is feasible to produce a risk-free software update
for this issue.  But, say, rejecting DH primes smaller than 1024 bits is
not, at least not along with other compensating measures.

-- 
Florian Weimer / Red Hat Product Security