Re: [TLS] Another IRINA bug in TLS
Dan Brown <dbrown@certicom.com> Thu, 21 May 2015 20:45 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 7F5EB1A8AC2 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 13:45:09 -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 WURZkV8G_10q for <tls@ietfa.amsl.com>; Thu, 21 May 2015 13:45:07 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id E05FB1A8AA4 for <tls@ietf.org>; Thu, 21 May 2015 13:45:06 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 May 2015 16:45:05 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0210.002; Thu, 21 May 2015 16:45:04 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'watsonbladd@gmail.com'" <watsonbladd@gmail.com>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AQHQkwYrGMmex37dc0iNG+rWIQqT5p2FORUAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX8AgAAC8wCAAAMhAIAAAqYAgAAylYD//8puMIAAaUsA///RelA=
Date: Thu, 21 May 2015 20:45:04 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5DDF130@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> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <CACsn0c=HuipCG20HGO+uLfBcm+bOEZQFdFdyKWsA1d5D3W0ZCA@mail.gmail.com>
In-Reply-To: <CACsn0c=HuipCG20HGO+uLfBcm+bOEZQFdFdyKWsA1d5D3W0ZCA@mail.gmail.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_002E_01D093E5.7D3232A0"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/9p3uq92eE5dK6Xab0a_YuDFHtbo>
Cc: "'fweimer@redhat.com'" <fweimer@redhat.com>, "'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 20:45:09 -0000
> -----Original Message----- > From: Watson Ladd [mailto:watsonbladd@gmail.com] > > On Thu, May 21, 2015 at 12:51 PM, Dan Brown <dbrown@certicom.com> > wrote: > > 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. > > Is that *really* what the recommendation says? It's true that using the same > group repeatedly enables an attacker who does an L(1/3) calculation to > quickly > compute all discrete logarithms together. But instead of making > countermeasures to this, it's far easier to ensure that the price this > precomputation is large, by using larger groups. [DB] That's how I read their medium term recommendation. I agree with them, and you, that larger groups should be the first defense (they call it short term). I guess that by "medium term", they mean to apply it in addition to the short term, perhaps at a later date. I think such countermeasures should be optional. It probably does make sense to postpone this discussion, with other priorities taking precedence. This paper seems to demonstrate that this well-known fact of pre-computation, which perhaps should have been anticipated, could potentially have real-world consequences. Past deployments of 1024-bit DH (and smaller) seem not to have anticipated this risk adequately. So, it does illustrate this issue here well. > > > > > Choosing a larger key size is the most efficient and simple remedy > > against these pre-computations. > > Exactly. No need to proceed further. [DB] The imperfect forward secrecy paper cites Semaev's example of DHE groups with easier-than-average discrete logs as a reason to not rely entirely fixed-prime groups. The current I-D FFDHE uses e to provide a nothing-up-my-sleeve NUMS property, so it seems like a concern that has been considered already. It seems to me almost certain that the current I-D does indeed achieve NUMS property, much like the Brainpool curves do for ECC. So, this particular risk seems minute, but it can be hard to shake off suspicions. > > > > > 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. > > You've just explained why I'm against it, better than I could. So what > actually is > the reason you support it? > [DB] Well, as I said it's only a second line of defense. I would only support it as an option for those who can afford the extra cost: the reasons to use this are not enough to mandate this countermeasure. Here's an unlikely situation in which it may help thwart mass surveillance (rather than help a targeted individual or session). The trend in factoring and FFDLP algorithms is that new algorithms are only faster than old algorithms above some key size. In other words, a plot of the new FFDLP algorithm's runtime against keysize rises sharply then flattens out, eventually undercutting the older algorithms. If this trend continues, then a future (or secret) attack may be flatter than the current best known FFDLP algorithms, in which case the gain from larger keysize is not as much as expected by looking at the published FFDLP algorithms. (Of course, the best countermeasure to this small risk would be ECDHE!) If all goes well, this flatter attack will never (has never) happen(ed). But if it does happen, and everybody used the same larger group, their extra effort may not have helped a non-targeted user as much as if everybody used smaller different groups. The risk mitigations provided by increased group size versus diversification of groups are rather different in quality, and are thus hard to compare. But for users more interested in avoiding mass-surveillance rather than targeted attacks, might prefer to spend their spare computational power accordingly. > > > > 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. > > Why do custom groups help? We've seen how they can hurt, by complicating > implementations, making possible cross-protocol attacks, and other kinds of > nastiness. [DB] Yes, custom groups have led to attacks, but that seems to be more due to some fumbles about ambiguously encoding them. I hope that once the dust settles a bit, and TLS puts more effort into *DHE, instead of RSA key exchange, such ambiguity can be resolved. In other words, any proposal for custom groups should be done quite carefully. > You're asking that we adopt them so that an attacker who does a > massive calculation gets only one useful result, instead of having to repeat > a > calculation they already did a few times. How many months of extra time does > this get us? > [DB] Everybody sharing a group creates a large incentive and single target for an attacker. If the computational power of the attacker tops out at some value (i.e. at some max bit-op per dollar), and we've chosen a group size just below this top power attack, then the difference is whether that attacker can compromise a small targeted set of users of one group, versus a mass-surveilance of nearly all users. To make it concrete, for a group whose size tops out the attack at two months, then it buys a non-targeted (mass-surveiled) user a number of months equal to the number of groups that have been used. Again, I emphasize, that this would only be a second line of defense: the first line is choosing the right size of group.
- [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