Re: [TLS] Another IRINA bug in TLS
Dan Brown <dbrown@certicom.com> Thu, 21 May 2015 16:51 UTC
Return-Path: <dbrown@certicom.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 8DC261AC3B6 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 09:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 43ChRMPG-ASV for <tls@ietfa.amsl.com>; Thu, 21 May 2015 09:51:31 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 851FE1A895E for <tls@ietf.org>; Thu, 21 May 2015 09:51:26 -0700 (PDT)
Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 May 2015 12:51:19 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0210.002; Thu, 21 May 2015 12:51:19 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'santiago@microsoft.com'" <santiago@microsoft.com>, "'nmav@redhat.com'" <nmav@redhat.com>, "'fweimer@redhat.com'" <fweimer@redhat.com>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AQHQkwYrGMmex37dc0iNG+rWIQqT5p2FORUAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX8AgAAC8wCAAAMhAIAAAqYAgAAylYD//8puMA==
Date: Thu, 21 May 2015 16:51:18 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net>
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>,<1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com>
In-Reply-To: <1432219967072.32353@microsoft.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.250]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0015_01D093C4.D488C2B0"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Rrb3bQCAahH5_ySpzDQH9y3FRVQ>
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 16:51:33 -0000
In the Imperfect Forward Secrecy paper, Section 5 Recommendations, the medium term recommendation to avoid fixed-prime DHE groups seems to conflict with the current direction TLS is taking towards named only groups. I gather that TLS is still planning keep DHE around (as a supplement to ECDHE). So, should TLS stick to its current approach of using named DHE groups, just with larger key sizes, or should it follow the recommendation above of allowing custom DHE groups? Maybe this is question for CFRG, since it can pertain to multiple WGs? If TLS opts for the latter, to bring back custom DHE parameters per the recommendation above, then it seems that TLS should expand on the simple TLS 1.2 ServerDHParams, by including the order of the generator, and probably including some kind of seed to a PRF (making them similar to the old custom ECDHE parameters). Note that ECDHE and DHE largely share the issue of fixed parameters are affected by a pre-computation across multiple keys. Choosing a larger key size is the most efficient and simple remedy against these pre-computations. Allowing custom groups provides a second defense against the such pre-computation, but supporting custom groups creates other problems. Peers need to verify the custom groups, and the groups need to be generated. The computation and communication spent on verifying custom groups could perhaps be better spent on using larger fixed groups. My preference is to recommend larger, vetted, fixed groups (e.g. at least 2048-bit DH and 256-ish-bit ECDHE) just as TLS and CFRG are currently doing, but to still keep custom groups (of similar size) as an option, perhaps to be added later after some further discussion about the best way to specify custom groups. I understand that TLS currently has the means to support an escape valve for custom groups, but it leaves the syntax entirely up to the peers to decide upon. I think a more specific support for custom groups might be a more useful escape valve, at least in the medium term. > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Santiago Zanella- > Beguelin > Sent: Thursday, May 21, 2015 10:53 AM > To: Nikos Mavrogiannopoulos; Florian Weimer > Cc: tls@ietf.org > Subject: Re: [TLS] Another IRINA bug in TLS > > Regarding validation of DHE parameters and how reasonable it is in practice, I > wanted to make some publicity for miTLS (http://www.mitls.org/). > > A miTLS client maintains a table of known trusted parameters, including the > subgroup order for parameters with non-safe primes. When receiving > unknown parameters from a server, it tests the primality of p and (p-1)/2 to > check if p is a safe prime (and caches a positive result in the table). If the > modulus is prime but not safe, miTLS checks if it is in the table of trusted > parameters and otherwise rejects it. We distribute miTLS with a pre-populated > table of parameters which we tested thoroughly (and we welcome people to > test further). Most of the time we hit an entry in the table. > > I think a table lookup per key exchange is about as reasonable as it gets. > > Cheers, > --Santiago > > ________________________________________ > From: Nikos Mavrogiannopoulos <nmav@redhat.com> > Sent: Thursday, May 21, 2015 12:51 PM > To: Florian Weimer > Cc: Santiago Zanella-Beguelin; tls@ietf.org > Subject: Re: [TLS] Another IRINA bug in TLS > > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [TLS] Another IRINA bug in TLS Watson Ladd
- Re: [TLS] Another IRINA bug in TLS Tom Ritter
- Re: [TLS] Another IRINA bug in TLS Ilari Liusvaara
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Aaron Zauner
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Watson Ladd
- Re: [TLS] Another IRINA bug in TLS Salz, Rich
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Martin Rex
- Re: [TLS] Another IRINA bug in TLS Peter Gutmann
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Yuhong Bao
- Re: [TLS] Another IRINA bug in TLS Karthikeyan Bhargavan
- Re: [TLS] Another IRINA bug in TLS Florian Weimer
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Peter Gutmann
- Re: [TLS] Another IRINA bug in TLS Yngve N. Pettersen
- Re: [TLS] Another IRINA bug in TLS Peter Gutmann
- Re: [TLS] Another IRINA bug in TLS Yoav Nir
- Re: [TLS] Another IRINA bug in TLS Antoine Delignat-Lavaud
- Re: [TLS] Another IRINA bug in TLS Florian Weimer
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Florian Weimer
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Florian Weimer
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Aaron Zauner
- Re: [TLS] Another IRINA bug in TLS Aaron Zauner
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos
- Re: [TLS] Another IRINA bug in TLS Dave Garrett
- Re: [TLS] Another IRINA bug in TLS Aaron Zauner
- Re: [TLS] Another IRINA bug in TLS Watson Ladd
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Dan Brown
- Re: [TLS] Another IRINA bug in TLS Watson Ladd
- Re: [TLS] Another IRINA bug in TLS Dan Brown
- Re: [TLS] Another IRINA bug in TLS Jeffrey Walton
- Re: [TLS] Another IRINA bug in TLS Nico Williams
- Re: [TLS] Another IRINA bug in TLS Peter Gutmann
- Re: [TLS] Another IRINA bug in TLS Jeffrey Walton
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Kurt Roeckx
- Re: [TLS] Another IRINA bug in TLS Karthikeyan Bhargavan
- Re: [TLS] Another INRIA bug in TLS Daniel Kahn Gillmor
- Re: [TLS] Another INRIA bug in TLS Andrei Popov
- Re: [TLS] Another INRIA bug in TLS Martin Thomson
- Re: [TLS] Another INRIA bug in TLS Martin Thomson
- Re: [TLS] Another IRINA bug in TLS Tony Arcieri
- Re: [TLS] Another INRIA bug in TLS Jeffrey Walton
- Re: [TLS] Another INRIA bug in TLS Tanja Lange
- Re: [TLS] Another IRINA bug in TLS Tanja Lange
- Re: [TLS] Another INRIA bug in TLS Andrey Jivsov
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another INRIA bug in TLS Martin Thomson
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another INRIA bug in TLS Karthikeyan Bhargavan
- Re: [TLS] Another IRINA bug in TLS Kurt Roeckx
- Re: [TLS] Another IRINA bug in TLS Kurt Roeckx
- Re: [TLS] Another INRIA bug in TLS Stephen Farrell
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another INRIA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Watson Ladd
- Re: [TLS] Another IRINA bug in TLS Jeffrey Walton
- Re: [TLS] Another IRINA bug in TLS Watson Ladd
- Re: [TLS] Another IRINA bug in TLS Peter Gutmann
- Re: [TLS] Another IRINA bug in TLS Karthikeyan Bhargavan
- Re: [TLS] Another IRINA bug in TLS Peter Gutmann
- Re: [TLS] Another IRINA bug in TLS Tanja Lange
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Peter Gutmann
- Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin
- Re: [TLS] Another IRINA bug in TLS Andrey Jivsov
- Re: [TLS] Another IRINA bug in TLS Hubert Kario
- Re: [TLS] Another IRINA bug in TLS Hubert Kario
- Re: [TLS] Another IRINA bug in TLS Karthikeyan Bhargavan
- Re: [TLS] Another IRINA bug in TLS Karthikeyan Bhargavan
- Re: [TLS] Another IRINA bug in TLS Hubert Kario
- Re: [TLS] Another IRINA bug in TLS Daniel Kahn Gillmor
- Re: [TLS] Another IRINA bug in TLS Jeffrey Walton
- Re: [TLS] Another IRINA bug in TLS Andrei Popov
- Re: [TLS] Another IRINA bug in TLS Nico Williams
- Re: [TLS] Another INRIA bug in TLS Nico Williams