Re: [TLS] Another IRINA bug in TLS

Florian Weimer <fweimer@redhat.com> Thu, 21 May 2015 08:02 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 482241A6F05 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 01:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.989
X-Spam-Level:
X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RAZOR2_CHECK=0.922, 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 Dai7sDJEH3WX for <tls@ietfa.amsl.com>; Thu, 21 May 2015 01:02:03 -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 37AF31A6F34 for <tls@ietf.org>; Thu, 21 May 2015 01:02:03 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id B2388293307; Thu, 21 May 2015 08:02:02 +0000 (UTC)
Received: from oldenburg.str.redhat.com (ovpn-204-20.brq.redhat.com [10.40.204.20]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4L81wGf025531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 04:02:00 -0400
Message-ID: <555D90F6.10103@redhat.com>
Date: Thu, 21 May 2015 10:01:58 +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: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Nikos Mavrogiannopoulos <nmav@redhat.com>, Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com>, <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FNesiFbGGmxSSCOfaeJ6HBrYOrY>
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 08:02:05 -0000

On 05/21/2015 08:10 AM, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos <nmav@redhat.com>; writes:
>> On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote:
>>> https://weakdh.org/
>>>
>>> Transcript hashing will solve this problem. In the meantime, you want
>>> to turn off DH_EXPORT.
>>
>> The interesting thing is that there are no DHE_EXPORT ciphersuites.
> 
> No, the interesting thing (or more accurately the MASSIVE SCREAMING WTF) is
> that there are widely-deployed web server and browser implementations out
> there that will still use 512-bit keys.

But removing that support is going to be tricky.  If the server has only
export-grade DH parameters (but does not actually support export cipher
suites), and it is willing to negotiate DHE cipher suites, you end up
with an interop failure, although you could well negotiate a reasonable
secure connection without a forward secrecy cipher suite.

Maybe we need SCSVs which express constraints on the size of the DH
prime?  If the server cannot match the constraints due to its
configuration, then it would not use forward secrecy.  That would give
(me at least) much more confidence for large-scale roll-out.

It would be a pity if, as a result of fixing this, more email is sent
over the wire completely in the clear.

-- 
Florian Weimer / Red Hat Product Security