Re: [TLS] Another IRINA bug in TLS

Santiago Zanella-Beguelin <santiago@microsoft.com> Thu, 21 May 2015 12:27 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 E49E61AD289 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 05:27:17 -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 VnSld5mN3iID for <tls@ietfa.amsl.com>; Thu, 21 May 2015 05:27:15 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2E21AD272 for <tls@ietf.org>; Thu, 21 May 2015 05:27:15 -0700 (PDT)
Received: from DM2PR03CA0002.namprd03.prod.outlook.com (10.141.96.12) by BY1PR0301MB0837.namprd03.prod.outlook.com (10.160.193.143) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 12:27:11 +0000
Received: from BN1BFFO11FD024.protection.gbl (2a01:111:f400:7c10::1:197) by DM2PR03CA0002.outlook.office365.com (2a01:111:e400:2428::12) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Thu, 21 May 2015 12:27:11 +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 BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 12:27:10 +0000
Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 12:27:07 +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 12:27:07 +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/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAJjSI=
Date: Thu, 21 May 2015 12:27:07 +0000
Message-ID: <1432211226723.39265@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; BN1BFFO11FD024; 1:R7xRTiWl8C0QmlOksIoYgJ4fyLdEjPxsQBxv5YCnp/rZkDEay7dPiEoSsEv4yOLtjX7OaHnRpmWRjtgio9p8lfdXtiDufE+4NS55dydPp2p2PJvfo1A7rhiIQvdZF3VJev5838PHYwumidjOeVtW8bnWKjB5zGjkZHMPObxOrEUS4DqsurIXiVXxoZ7lqmmWSgPbZ4JQJqG3g0lrC+7lCruTuyDVinH4TemPoQZQceikukbGT0112m46NxeQ6XsZnXhKrOc7d1Q+MVun0Z1X3giLRT7c7Je+N9nmvIlwtg+2MfPzI5FXBcKlgJ46tYVT
X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(189002)(199003)(377454003)(479174004)(377424004)(51704005)(36756003)(4001540100001)(46102003)(97736004)(92566002)(23756003)(86146001)(2656002)(87936001)(93886004)(117636001)(2900100001)(81156007)(19580405001)(106116001)(16796002)(102836002)(106466001)(86362001)(189998001)(5001830100001)(54356999)(76176999)(5001960100002)(5001920100001)(50986999)(5001860100001)(86612001)(64706001)(5001770100001)(2950100001)(6806004)(19580395003)(68736005)(47776003)(77156002)(66066001)(69596002)(62966003)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0837; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB0837; 2:wT58P3rC1AQocNMqH2IsHKD5SFEVh06WTzbwyTrLcxUi0TPKa2fVOMUK28X79yCc; 2:ccPMRX8TKE8mKTOVfzBR/HP+wrFI/lYFphQVTaYdeBOCGVtN+8yHSopkiRYvTNw3yyNiUi5pnYijZ5S1QlpU6LgFw8IvNyg0c1G1C/XMVhwTM58mNUsMkhneSgQKtVogWWCpM4+fbfBiyPbZ8/XqDYw+eQgiY+11hQatRCpzR1UnVyg/dbGj6Zw2Gxyvm21XR37rFwyVBIHikkdUbqcTgDRCmjieLA7aAMfVbcT+YAt9BHFjhBCYAPOVniFrov97; 6:cQ9Rm1VV6crrTNYYnG9vXS8dwHe7254VOzEFHM7eXrcJ0SXV1pM6l8jQgJKitqJHJ+QaC/z85ahidjhoy+ELi3w82B3GRcYqD23PN0DINdwZkQr3WPKLdqWs6ckxFx+09Mr90HetDUb3FlvOpnr1RB1UnkZNeouedLJF1vk7FLygKTianWOXIUjOpS3Mqh3zdXITvd4UCuts92txviSM08c4XgofdGqLvvnpZsV7FqxoLUshbvUDEvsrtiSg+DqwV9KsRGbRWLiYBirZLTtd5Bcy7hIO1yatXdVMl3c9HXgJzjfhmj4GBD+91mU+hsL22PHoD8Z0WTchVo3K6e4u/4znyqpSTAbGtCkPZIn1gCje06CBM73iHpq6rtNKyMG0kkLKUlGRcFT++ip/FTYyW/NRmEQDX+hOAGxKRHUVTsvEFui02zE4XWbAnwpiG6lpsXQFBUmED1oRDLXoAyqNV2VarGRdNpasXddGguFTsFzgvf03LGOqk73WjtE3KVR3
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0837;
X-Microsoft-Antispam-PRVS: <BY1PR0301MB08378269DDF0EC6A0EBD7695C9C10@BY1PR0301MB0837.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:BY1PR0301MB0837; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0837;
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB0837; 3:JTb0IMQuq4Zvir/GNk8RI+FZfSKbIxgTKv1RLzoSw2UIWL1/KtsQNEWk+ZLxbN19tlRzZoer/sX5cPGfF2tzmSAfj70Bn4W/uVXCqRmqYmTmGkPNf32H4UNpJhNZ3T8xIa68D1sgv1q2daGeUALcSa9LurzXaxVcOnQeAHtNW2M+HPn0BE68NeJKpdQ3lUGck9Q8blGAZXO+D1kqv4S88STvHkUF1Dy9QfVj1m/aTlFbJIHr8RzbND2PHsh0j7xUznu74O4CX2NsRQdXu6gQJ/2b27ZfbA6vshhcGQ+p1GSwklKyc1v1H1F/9F4e22dg
X-Forefront-PRVS: 0583A86C08
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB0837; 9:B9mrxLd8QUo4aQ3ZQvpDQNgFIPb/l6GZdWDsmk+D1x8SqzfECkonBBjT2udzRLNyQhbpm7sPo80ff4vZPk1ybYc3Vy6N/Zz8IgF5SA74KkQnWFeRCRDSeQtFNxKGfhwFmZHJ/bbGiMUq/vCsr4/AQBV2q6zuq013DUADloTxHeZpoQyz3Aojp7IF3Zhd2OQ8q2durPcGfgiUdxTALSKtuUdmJUnQVot0nsicxe2eywJ7AOxdwWfOxEQzYLeEo2W6BKhPSdZj0vesJQzAWwOTw2m08f9xd9CfdH36Srl8/1O1iZu07h782qiMf1CKUELStDdXbMr7impTNOjA/E5aR7VnGJJRlrxLtoGkGbCH4y0OPLqnI21wQK8c4UydYFxaOwB0KTw0db0BLQLppuh3z94qrjuuQsocxMGexwcpCKLMnjgg3CGL+eRzrHbuZWkrVErDq52l/u3SxmutONo1NQacBdm1i9RlXk1H9SCskqqVhXgtSzZ+8u1R9pu1jSs5f4VrBRfPrl1dJ+H7SoJ8wlHhfQP0T7KZVWKNv/UsBWWcLtq4XV12rJH1AOA8Qhy4HFt1XMgzvCJm7vv6wNieiE9KP4yfUYs2BWpMv3QIIvclIdbZ5uPbwcHtvM2JYBbI9+X6c2F+21C/78yi4P2CXsrJjbhQaV9km9VC/xIvppIL+K1OjsmbClJLePA6IwAsiY2xla1/AAQQcjtwhZzcztsb2WCAxkhyVIEpJgEXdhlGyJG2TitzOo1HzfmVL2kCzZ9tVkmsVeOBk7KG1BrC+ehS50IK/JMBrct/2QLK6bp1sui7ENM9rnW9byS+4deJJ6x5d2rILrjSnKzdMiX1q7KgyeNKxZQ5G1ebPApizSTUMYx9AZ3C3L8d1b9fnKBC/Bo+Uf7qqPx1yPVDf3Y8H1imYxNXpBd+sK6tPS3qebOPxlbeyhRst1ML+bT6Yki2piIiOM628bFWwpqW3TncEqStXOqz5U1U38T++K7U7UYrTRBt+2QvA6qojOSG1SyYZxeO6qfvLMEh4wdZl5aJijLzVW/7IwxHKUDC5d6ztpBWeb6Q1hedf/BeTuHaLNT0JdI3vLatFvgrE21Dm8VOg5xdFRXr2qVF5zvlmPnr9Hf+DHjcSJvHfSSy9kjiDHNlBJ5fPJ8GIuBvZfVaJcy85JIawHGYWzRTpX1CDYKakeKBzMV+nJiFbUXws37s7nMScyuOmTNmRnK8pu81NGee93xYe19X34SE00XMJEVwRD/onjuCEffUoVdk2hGuvri0
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB0837; 3:SlwQp12b1NoDksA+eld8+3GdU+MymBMrd9RwnghDCaj2MyAJJ1LyP29uNk6AYht95dVrMN8z+PLTocE5kPpyZsmyJrPW0DihGIrVqcwuPY3sIygjsDWi1K8cxka5kFoZi4iqVHH7dxZnfG5lIc30Mg==; 10:jEU9ikztGsx2F2L1YnJlo3MZaU5JTOHB5LZgxPT7qwqzUHikD7HSAgPLbt75Ul6Ar4kJ7VEUMAbd6ZFb22+xtEQA+KK04pADyV8k/o2KF/g=; 6:g6CLktmAFm2XUoEDRbsnf7SJWO/Ve5hLN3ztuoQd2llfT1vEqeTu7TDfRUmSwWxr
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 12:27:10.5932 (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: BY1PR0301MB0837
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/R0Qr0GcEMj22oxymvzW9ioxfKcM>
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 12:27:18 -0000

> 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.

Yes, non-safe primes should be first deprecated.

> 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.

Checking the order of the generator for safe primes is ridiculously
cheap: just an interval check. That's not the case for non-safe
primes, where it would cost you a fixed-base exponentiation. This
assuming you somehow know the subgroup order, which is not sent in the
TLS handshake. 

I think it would be reasonable for clients to test if a DH prime is
safe by running a few rounds of primality tests.


________________________________________
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