Re: [TLS] Another IRINA bug in TLS

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 01 June 2015 22:27 UTC

Return-Path: <Andrei.Popov@microsoft.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 C036F1A0389 for <tls@ietfa.amsl.com>; Mon, 1 Jun 2015 15:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 C0epYV9gGuAz for <tls@ietfa.amsl.com>; Mon, 1 Jun 2015 15:27:25 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0751A0393 for <tls@ietf.org>; Mon, 1 Jun 2015 15:27:24 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 22:27:23 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0172.012; Mon, 1 Jun 2015 22:27:23 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, "noloader@gmail.com" <noloader@gmail.com>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AdCUn0KvGK03Jhi6XU6uOngiFXH3wAAEj+eAAE/awQABr/SgAAAB6bow
Date: Mon, 1 Jun 2015 22:27:23 +0000
Message-ID: <BLUPR03MB13968553F532B2708D1194EB8CB60@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <CAH8yC8=F3jJgEzFQSN=ZMvoC4zunAsfHPs1k2km9dvFJ0bvg2g@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> <87k2vncei9.fsf@alice.fifthhorseman.net>
In-Reply-To: <87k2vncei9.fsf@alice.fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 3:IYICH0prH2bOFnpif7RAJGUaTbWZHThFUPCmbxRrByZhVtccYRq4nLcWpIQOah6K9bQa3n2IE5s3u2Wcrbhd+PriqeQtZauJHCN7Pj/yF3GSG/P1cSNfLRlDdwO8woqq7Ptt7Pjnb0Og7fVxX7EcNQ==; 10:Vc3lvlF624UpOa3YoKZ3dGM0Bd+Xz7AT2Jln43gsTqc3RIoCKj53pQTrNQdDMvxpRXr2CgUJ8CWfDzlTNRcVDy1665BzCJLwDNagdWdD+Eg=; 6:1jB3KTT6FZWoNfAn3ktcpZ7ESxLQV4y5nv/e5HAOtH6Hth9UZlwTatoQAilhzf0P
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393;
x-microsoft-antispam-prvs: <BLUPR03MB13937C4C8E740D36DB5A2CBB8CB60@BLUPR03MB1393.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393;
x-forefront-prvs: 05947791E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(51704005)(377424004)(24454002)(377454003)(189002)(64706001)(86612001)(2656002)(62966003)(19580405001)(87936001)(19580395003)(77156002)(40100003)(33656002)(5001770100001)(5002640100001)(97736004)(86362001)(122556002)(105586002)(99286002)(74316001)(46102003)(81156007)(93886004)(4001540100001)(101416001)(106356001)(5001960100002)(50986999)(5001920100001)(5001830100001)(5001860100001)(54356999)(76176999)(2950100001)(189998001)(68736005)(2900100001)(77096005)(15975445007)(92566002)(76576001)(2501003)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2015 22:27:23.1591 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wfNjMmbD-ZRwz3tEM5EhZ9KQRjc>
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: Mon, 01 Jun 2015 22:27:26 -0000

> Standardizing on known safe prime moduli seems simpler and easier and less likely to include some steps that people will be tempted to skip for speed.

Using known safe DH parameters makes sense to me. Besides, if we want clients to validate arbitrary DH parameters, then we have to standardize the exact verification steps, otherwise we'll get interop issues.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Monday, June 1, 2015 2:20 PM
To: Peter Gutmann; noloader@gmail.com
Cc: <tls@ietf.org>;
Subject: Re: [TLS] Another IRINA bug in TLS

On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote:
> Jeffrey Walton <noloader@gmail.com>; writes:
>
>>GnuTLS with its Lim-Lee primes causes me a lot of problems because 
>>they cannot be validated.
>
> Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as 
> well!), it's the fact that TLS uses the PKCS #3 format rather than the 
> DSA format, so you've got nice verifiable values for which you have to 
> throw away the parameter used to verify them and send them in an 
> unverifiable format.  Having said that, there's a pretty simple fix, 
> define an extension that acts like the existing propose/accept 
> extensions that signals a change in DH values to the DSA form (p, q, 
> g) rather than PKCS #3 form (p, g).  And for TLS 1.3, use the DSA form by default, not the PKCS #3 form.

If we're still shipping arbitrary groups across the wire, then adding
(q) to the data over the wire not only increases the size of the handshake (by the size of q) but now the receiving peer has to verify
that:

 (a) p is prime

 (b) q itself is prime

 (c) p is actually a Lim-Lee prime

either that, or they can skip the checks and cross their fingers.

Standardizing on known safe prime moduli seems simpler and easier and less likely to include some steps that people will be tempted to skip for speed.

        --dkg

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls