Re: [TLS] Another IRINA bug in TLS

Santiago Zanella-Beguelin <santiago@microsoft.com> Thu, 21 May 2015 14:52 UTC

Return-Path: <santiago@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 67AB51A1C04 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 07:52:58 -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 gwdhwdVUvAjX for <tls@ietfa.amsl.com>; Thu, 21 May 2015 07:52:54 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149F51A1BD2 for <tls@ietf.org>; Thu, 21 May 2015 07:52:54 -0700 (PDT)
Received: from BN3PR0301MB0833.namprd03.prod.outlook.com (10.160.154.143) by BN3PR0301MB1201.namprd03.prod.outlook.com (10.161.207.154) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 14:52:52 +0000
Received: from BN3PR0301CA0008.namprd03.prod.outlook.com (10.160.180.146) by BN3PR0301MB0833.namprd03.prod.outlook.com (10.160.154.143) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 14:52:50 +0000
Received: from BN1BFFO11FD003.protection.gbl (2a01:111:f400:7c10::1:120) by BN3PR0301CA0008.outlook.office365.com (2a01:111:e400:4000::18) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Thu, 21 May 2015 14:52:50 +0000
Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none;
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com;
Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1BFFO11FD003.mail.protection.outlook.com (10.58.144.66) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 14:52:49 +0000
Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 14:52:48 +0000
Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 14:52:48 +0000
From: Santiago Zanella-Beguelin <santiago@microsoft.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, Florian Weimer <fweimer@redhat.com>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAvugQ=
Date: Thu, 21 May 2015 14:52:47 +0000
Message-ID: <1432219967072.32353@microsoft.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> <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>
In-Reply-To: <1432209104.3243.65.camel@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [92.151.241.88]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD003; 1:JJs0oSgPFkiTvqphjxsGc4Ls5JYgJhv1jNtxVQtP60F/jEQW+kVOq9PGEnIB8/S5PWPr+IBSyazux+lU4ob/2HtjWq+Lg2guRnS9yG1pVtxFejmcKw0NSak6ed0NbahH2Dlq5hE+CO0D8Kq4sueBRlsBa4kAaHMxQC6guKIAyXyIroq6vXZm5BMpUOiAx0yp2UszW1SL+XAdsjzncQyRwpdcDl4te3G8/xm7UtsjnQfC/g8mll8rv2hmrjE8LyL9o3LF+42Yt++9eDpPAJwTWlRoBHeeKFb7MOYpfx3VCzhi9R7muBKTOUFvWBYqbR9R
X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(51704005)(199003)(377454003)(189002)(479174004)(377424004)(86146001)(4001540100001)(2656002)(93886004)(102836002)(92566002)(68736005)(50986999)(46102003)(86612001)(15975445007)(81156007)(76176999)(86362001)(77156002)(16796002)(54356999)(87936001)(5001960100002)(2900100001)(66066001)(97736004)(62966003)(2950100001)(117636001)(64706001)(5001770100001)(5001830100001)(5001860100001)(23756003)(50466002)(6806004)(106466001)(106116001)(69596002)(47776003)(189998001)(19580405001)(19580395003)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0833; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 2:mfGAOEMeKoXNWIXDBt8j+mhss0qohZLuCxy35fvsyFtlBpa3Ol5cijiwJ8B7NB6a; 2:6+uWm+eloNvEHsJ64dSxrE4JJ6nr3Md/tyKZVtm2kuqnqinxbomNrfafrNoRA4OSCFfWnbDoxy4Obgi+V+gT+Qf5z93vFicl6Fv6end67Tq4izlP7pON8zBxMfuteiPZwJKobYmlM9gJ9WLyhvrvJFHFy/fn5l5U76MHTUwmmDBrWfLuqlADgJkQ+GXqKmBZJkMyarHpbyonzzirGTobEFPBdZj5VzfYiLQe72G9Fl6PcguGR7iJ6XZiwIYBIYI/; 6:XC7f1iZoKYnXBgNBDEilCHsZtkTN6RczlhkYwwqJQ03kTBX78nIwuhcIGMo5QVldpU0+QZUMjxcfivYwvwQSUPq1pVm7jvrA89S2Ic2RMeNN2IJpVYVGWaCZPYwHyRx05uaZUa6ZGu0wcOLIYwFlyAFW/5oDniWH43A7tQrVBOzTw7UVmDiYH/qAMaLiYLeKcXojMS+pR9ATFy6sQYdHraM5vYLLIjdqNqA0RN22Bgb175FZbDPU5PddcigC4HooGgDuhak+gfTn6CT0hLBfDDqrowst6RwmelXzUuxEFRC0wUxAZaTXXiejVumyx/549eZY30a6m+GIinS2soH/Fipi5v9UoXqD2tfRbkpWj06gLsY24G9TR5bz1MSDg1lUn4o+8/do6v3cpNKAPTc52XkAXwakLlQaUeS2w6yAkLobeLNJ26DGpW9bRfGVNaPxD7Ye2mwkGZZM8/McXD9T+j3qPPu9bYi60ZByo9TAUF1GPe39OQbzdbPu68G6N/4y
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0833; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1201;
X-Microsoft-Antispam-PRVS: <BN3PR0301MB08333BC0AB3EC93DEFDF82DDC9C10@BN3PR0301MB0833.namprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR0301MB0833; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0833;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 3:BYBct1vdwRUQW8muthQiCWpw5jz5wYAafRVMiT7tYjFCNvxF76UaN/qLHV40Yg1A/diVa9a25KgrjE2e4DMCQU29Yay6+wnlp86EJHiqnVNLfh8rdqXrerWc1p+RsWC+unXil0PI+TFYegpApvbexUS9mmUL1m6xU0GQGj2KwOqNFi/urMcujioaUMdjEkFlSS4NZGsaoGTlLgdBSl7qX4I6/6XvXh53IW3HYaOE5SoMBTWaPo4KZ+vN8mApwy4KnWcx/69mZGb/DYlN7MbBFrqryW0HT7J+AQnuzRbi+T6rLY4Afas3wuUhMRpJsvZu
X-Forefront-PRVS: 0583A86C08
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 9:77suTGtu3MOigzTChTImtTwgwxGU7SSBHwENfvwExqwA/GindXc2BUhSrpptuxiLq3qFVMGF02xbPTmdKVLXKbxzlBlcaQRNrSkK7Fu1IImCI64LJR7AqqvyhT1ickgUNdD3GQVCSCJjPfjDTk6xP0c9/+b3rpzu5yXuHCOGlB+JsY6+1WJPHXYyOsCksfCvnuK9TmQm5pY7ctNlX6tjqVz8y9TCAKPj213PLdPqw0dTPIPpxkqXKsSxbt608md9htacpquog6jC6R+geynzDqV5bLQHKEo/KAEckQtuGRlpHHSzyg7qRWefTXDasnYWXA6jmsBHkQko5qRLSh7lTkW7Hj43uSulaYKcswu/4/tA0gaMVrXpO/9oBo6PfgJd/7jf8Nxa+2cluOwll4Os9bZeLJTyufSP//5Df5zGkE+CGO8hMKIeKbQ/qDNeK6kdCEvjQeLVYcPsSdMqFNXaU1a2EctSWTRuSUI+d6mvSDqZhlZzfJcTXkoYzAo2XZb8Dv/vP2J7kdqZ/8mG7K2+y8z5KAN1jsmYrQJ22Tfw/po+ONi/3Jd7wJNBs0QDwdea62peaKMPbQXOeI7E+aOgmOAR3TAUsXSkFeEUMD7NucbbxkEPhuA8S9NhTD47DUYu6j++LQjSuWIXMRV4yHxigw8QAbHCfTOSpmJP4+H9pLtBo/krN5yxnYPMxV1PaEiRsoBt8mUtUabW11nh5RN1Fa1eWqruhAARuHf7sZKbZeWHUJoXP2uvk5lSj5gw3MQzJs7T/7yyJZAaGMA2akVBZg6cwWQLu4nOAhqvPNi9X6o3RFAbnwdttb5R/XNbu3ujA+iYU/m/vsopI+FUaITivbadZ3gCH9F0VPmz6b1rlSAm/l3fhM6PjoRHZFKFfOkwfd1WgOyzyfy8jnp3QcdH+PLN3SQO7ITwTIEQUUX2HGpcR0GZveGEJScM2GfnfSxbHu6on4nWIurEf5uUEp/OrZ9J8cNXgCTxAzXjxkbPtzGv5MHvXNJs5HK6//9IPhl+1oLxeD3LET6FCGtugOYBnW6n3SpLxoBpUjZ3+uV9uoRpgpN7jmhbqifaSOi3hxhInd370tyD6jDNdHBy6R44zUuifBds1sjljAZ5/x1E315kwKjWCUd78ZOuCBHEc6/usr6qenLEfmSXuXC8YeF0SQnggyp+7LTb6nUgMBvcuhp66tbMMD856lvxyWk6ALDQc5/FoxaLJ3IQpLWYp5+psOJVirxTKc+vLVp/fQcV+3FkFcxbIQYUoNR/7XTJiD4g
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 3:GvOj0YN5zA2illPw8lUMx/Lkfw23Z0MohEj8iDf9BLBHit+ZQ+5wJPSX1z5TkfWBzFkLeR0TQa6ioWaA4b7ZBEf9itaOUtRU9ORncyclTz8zDa/ViIU9KKhA+U0QQVLpOecWAowSZRXznOhdtmv4Gw==; 10:nFo2v0ru4xQBdQw6/DZ0HltAS15i2kCNRjUwd5xDSayHkk/kZuUigQwA9q7QrSo74NZTMAVFJXgijyEowZbABY/UV3RzFbTjRVbucI0wWYM=; 6:WwIPaj0vk7g3b1UR4D3uluQfXjv5B71LeDkDOF1vmITd/wvTty4nWEAHltICr2AA
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 14:52:49.4692 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0833
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB1201; 2:ChLcWRiqxBHRfXQzoPmLNbn0Va7x4unXPBX39V3VOZ9XPcYEBxtpCXnmfeFqz89J; 2:ExWIiwKJ81h/v9r7ROSK+3wYXdP4OUkYhA9WI6rnGBHJMHpKbdA9+rXQ+frhaDz34sG7hwJ5hBYDpeuGGCnWCUfpp7XFk3WzH4cF/9aX1Jw7E0ZS+UVbKUT8mWn3FgXn/B26HszwJt5r8VK8mWfw1zCD2pKnj38tg9wYaU1Q1e2MGNhEhixYNxzW7T65tpHGo1MAPxuYhA4DlbtxDJSVJldrvdngxqT1QN63OwGg6egWlYTV7huET8sshOMpUJ0I; 9:rJtNOKatQSyKXzpagdhznGMeuJkLOAzHCbBP3AKhg3M13VfGDFMBD0H9dxsFE98DoIxpNCpo0aRPTcoPmK4VBs/EipprvqYq6nlV9+MePH84yKIb5vT0jTV6koNqzYU7+FwLTdw4LZ8ISFMYS7nR7A==
X-OriginatorOrg: microsoft.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/XHOv2NifoKSjpfFX2h3kChoM2Vs>
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 14:52:59 -0000

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