Re: [TLS] Another IRINA bug in TLS

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 21 May 2015 08:10 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 9BAB61A70FE for <tls@ietfa.amsl.com>; Thu, 21 May 2015 01:10:03 -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 kCafKIMd3bav for <tls@ietfa.amsl.com>; Thu, 21 May 2015 01:10:02 -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 4A9D01A6F34 for <tls@ietf.org>; Thu, 21 May 2015 01:10:02 -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 (Postfix) with ESMTPS id 17F098E6FE; Thu, 21 May 2015 08:10:02 +0000 (UTC)
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4L89xS8013552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 04:10:00 -0400
Message-ID: <1432195799.3243.18.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Date: Thu, 21 May 2015 10:09:59 +0200
In-Reply-To: <555D90F6.10103@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>
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.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/LDQYxte67PscLYFkybIrTMpKMIY>
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:10:03 -0000

On Thu, 2015-05-21 at 10:01 +0200, Florian Weimer wrote:

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

I think it would make sense to push for adoption of:
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09

However, that would not solve the incompatibility issue with old
servers. For that to happen, either the whole DHE ciphersuite space has
to be reassigned to new numbers, or move the DHE ciphersuites to the end
of the client's list.

regards,
Nikos