Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt

Hubert Kario <hkario@redhat.com> Wed, 29 October 2014 11:16 UTC

Return-Path: <hkario@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 DCE601A1B2B for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 04:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_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 4uCko3WQxN7r for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 04:16:05 -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 556161A1AEE for <tls@ietf.org>; Wed, 29 Oct 2014 04:16:05 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TBG4gs013722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tls@ietf.org>; Wed, 29 Oct 2014 07:16:04 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TBG2mA004869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 29 Oct 2014 07:16:04 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 29 Oct 2014 12:16:01 +0100
Message-ID: <2907933.P1NLlWJtQy@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <544CAC9D.3090909@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544CAC9D.3090909@streamsec.se>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OgwGmmIeSAL2aAg0312WpdK6FBM
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
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: Wed, 29 Oct 2014 11:16:07 -0000

On Sunday 26 October 2014 09:11:09 Henrick Hellström wrote:
> On 2014-10-26 08:09, Nikos Mavrogiannopoulos wrote:
> > Note also, that the current approach will simplify a lot an implementation
> > that doesn't want to keep the old DHE key exchange with arbitrary groups
> > (and unlike the other key exchanges in TLS, DHE was the most problematic
> > compatibility-wise so I guess many small implementations would be more
> > than happy to drop it).
> 
> I don't know about compatibility issues, but rather see a security issue
> that SSL 3.0 up to TLS 1.2 didn't explicitly require the DHE parameters
> to have a bit size greater than or equal to the certificate public key.
> I don't know how common it is for clients that offer DHE cipher suites
> to be able to use the server certificate key for signature verification,
> but unable to compute a DHE handshake using integers of a comparable
> size. I doesn't seem reasonable to expect this to be a problem of such
> magnitude, that the standards should keep an acceptance for low(er)
> security (than necessary) in order to keep interoperability with such
> clients.

That's the case for nearly all implementations of Java. JRE before 1.7 support 
at most 1024 bit DHE, while will support 2048 or 3072 bit RSA just fine.
1.8 only increased the limit to (IIRC) 2048 bit for DHE.

-- 
Regards,
Hubert Kario