Re: [TLS] Another IRINA bug in TLS

Santiago Zanella-Beguelin <santiago@microsoft.com> Fri, 22 May 2015 23:36 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 BE3591A8849 for <tls@ietfa.amsl.com>; Fri, 22 May 2015 16:36: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, 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 NDHzmSSPvPRh for <tls@ietfa.amsl.com>; Fri, 22 May 2015 16:36:24 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5006D1A871E for <tls@ietf.org>; Fri, 22 May 2015 16:36:24 -0700 (PDT)
Received: from BY2PR03CA039.namprd03.prod.outlook.com (10.141.249.12) by BL2PR03MB353.namprd03.prod.outlook.com (10.141.89.16) with Microsoft SMTP Server (TLS) id 15.1.172.17; Fri, 22 May 2015 23:36:01 +0000
Received: from BN1AFFO11FD046.protection.gbl (2a01:111:f400:7c10::180) by BY2PR03CA039.outlook.office365.com (2a01:111:e400:2c5d::12) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Fri, 22 May 2015 23:36:01 +0000
Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; redhat.com; 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 BN1AFFO11FD046.mail.protection.outlook.com (10.58.53.61) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Fri, 22 May 2015 23:35:59 +0000
Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB031.064d.mgd.msft.net (141.251.50.211) with Microsoft SMTP Server (TLS) id 15.1.112.16; Fri, 22 May 2015 23:35:57 +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; Fri, 22 May 2015 23:35:51 +0000
From: Santiago Zanella-Beguelin <santiago@microsoft.com>
To: Kurt Roeckx <kurt@roeckx.be>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAvugSAAch4gIAAUHiS
Date: Fri, 22 May 2015 23:35:51 +0000
Message-ID: <1432337750554.95436@microsoft.com>
References: <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>,<20150522175618.GA10423@roeckx.be>
In-Reply-To: <20150522175618.GA10423@roeckx.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.216.4.228]
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; BN1AFFO11FD046; 1:w1AN/3E9vaA6C2ts7l4etTPXneuHeENSy862+7aGsdae3Y+qzxsW8B1tdQHbUpwKVzageBT4TqZUw3sreZr/b6zgQMLMieusnOGrLoHPmoXq1p+plvprABlWvlXCGdip7kv5eiCC8OJCkJ5lRhyKcVaw4c1aYkhQznri/UWymv/MTpt5Nmk5WeGVE678BdRN8tKvThAB/b6LwMC8v8yl+o5hTTyBFnlrOJeOLh75fWkWeGa02SPwl08B6cKEkKcjaDC7PV+M6+w34lJYezJRYmCg+NDmgtYUY3+X/8YOnC6ymuth3fOjUkbgrVOquTy6
X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(189002)(199003)(24454002)(377454003)(16796002)(19580395003)(76176999)(19580405001)(69596002)(102836002)(2900100001)(15975445007)(68736005)(2950100001)(86146001)(54356999)(86362001)(50986999)(36756003)(86612001)(46102003)(81156007)(4001540100001)(93886004)(50466002)(87936001)(2656002)(64706001)(47776003)(66066001)(23756003)(106466001)(5001920100001)(106116001)(92566002)(110136002)(97736004)(5001960100002)(117636001)(5001860100001)(77156002)(6806004)(62966003)(5001830100001)(189998001)(2004002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB353; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB353; 2:V6mVVACpikg5lZ+MHKeYYN1/ujpxtFjjdBwK/6dcq+xiXu0TSazI5niTxM+bNoql; 2:CHkByA7K8b/GTu99z3E1Nkn4lTN1ZdXDl4n4+ZshX8UCOxRlMzhtc4fR4QQZZcYmpfaQ008Xl0hNkdC5DzvsPl/uwF2d7ZDnpMS3AJHHbMYFaIE3PyXyaRhBSYTAVzS/ef4ut38e9p62N8WUwDSKYTlewqgKaRPsppWT14t+CfJsft30dZg9E68BT+KVNkzVYv35YYu+xCm2yDhYhZ1IXvEPa52QrBR3M10Ad261j6WKXIohSn62NXRszKZH8aaG; 6:k8eGIPPHEDrLUbfRm1Xk+IG6NWsm3MhqmUoCoNKXbOQOgpmkidAlK5LfBvzIsOK/gVOfUtROR6tIp4qf8GlscQg1TidN2JWfmGmSGlGfbQjN2W4pohSRANmK3KPqAIsumAuKqOwfdnw+6f6kI93YDgiETyMXMFQeXiC0o2ba2/YPrZfhwqYMUaGMA0ixGpF1Um5IBZAmdir3+alStQkzAusq8BIBhscUUOonOJoPuEXCmNX4oUVCa9EMTasut6J6JYvLHtoUMLhlT3juw1V4qNly8xIvZULyUG2qnoAK75i99G9RIUT13/DBx3u+2RKFiekDj7GaTrO4kbJtGwatN73uhcV2fJssS/sq9eBdbDLoH+jlvTin+cD45ea0XHpyPGBjcwz5sE+NZNAkMxQXBd/cY2ra00nT1dSG2Yvhr37nUiTlmo5TnXqge0zmVQSYMbxFR3sR7UEcgvesr3aW1GeWIFlPoROgm/G9hvIWEJfXww8XUA9JcAaqlhfp1e4B
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB353;
X-Microsoft-Antispam-PRVS: <BL2PR03MB35332FA839ED65EC19C8AEEC9C00@BL2PR03MB353.namprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BL2PR03MB353; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB353;
X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB353; 3:Qq/fjcrpZNcI/ZVN82XIyLA1hrHT2jFpT2Lwx73tmB+mOjFpMuQCBWAlHW6rykVL2QHmHKMGq2f51QlzCURqXaodbgn3BT7acVUpzwb1emufPwRAuvzRY0+vMRXdZX2uHMIOKfI/9INDWIU03wbYYqqhpQO3PGBRWkmJlEphxFXay+YPcedgr8JbQdZy2vtgmWsXBBEa1pjYsi9Yi+8iRrFfGY/N7mMLULjUVbl7UoKCzqjGpZX09QWRvZSqxPHdHS0MRtp1heee0NJJukm5z29zz3U9wVmz1mDwuXXEXG673ud3DUj2pfzlXoQV4RIaRvtC8XjwEQ1CMGiTyLvXRg==
X-Forefront-PRVS: 058441C12A
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BL2PR03MB353; 9:MQPrEk8dVerVbRGhm+Kp/JpQEb39rgNIjzBvIpRL9?= =?iso-8859-1?Q?ZSE+pJmXR2jV1awhnEXdS6PIex6dykDnJsBfzsRxIL9ukJ6X4CCeT8kS6U?= =?iso-8859-1?Q?6HyS2pRgWViJr/BKm6qZym+j6PyKS2v4Yg59ZgyTc87ZO8o6K2h04cuo4q?= =?iso-8859-1?Q?7J3IRwdi3oYI5ue2xiwST3WbWmilCgsa5pYe7/rnl5Y+1O9ImrRo8rHdRN?= =?iso-8859-1?Q?jGlSGhspOrQpOHNgH5BugjnR2anJkp3n1tK+pOqL3mIFEZ2sFK7wTO7szI?= =?iso-8859-1?Q?Zjgv5aiutkCSnvikvuRTxV8IVJOkmiBkCVlFxKamo5capp7sY3DjHbzIBV?= =?iso-8859-1?Q?HXs2hPrVKMU93U2O4fH3qRHtw+Cmy0p0NvWDCUsquDp3SMZXOt6J83+IzD?= =?iso-8859-1?Q?GGI6wAjKSLgLSP6qx1xq4PvN+9s5CI43h9AGYm5KWqmmXbRB6rSqeMmWny?= =?iso-8859-1?Q?Nn8U9x+cK1NLtQf6I3POHHCfQa47Fxv/FwQaRNOPSmQhAKCuguUQ/HvuY5?= =?iso-8859-1?Q?kxcn3xOr7mUIhQWb4h3ldV8vQ8Zc5hfWNFVjvJwUbVjOByXuIOwd3zpj6+?= =?iso-8859-1?Q?Rt+Sf/zU+VlThvhxxeDG4jIX2PkFskdEWDl/Z4QeoAzQVCTW7h7xCO+9W1?= =?iso-8859-1?Q?K0uFtKQQAjl735QmbMahtBS657BsCZUAVPFPUlpL9a1n3sgcYBkpWhPfLD?= =?iso-8859-1?Q?B+n8ICC2BKWW2gA0JsXRiuOBmpdDWv9l3NBY1z125KecirzOGCEhcSX8Tf?= =?iso-8859-1?Q?dnSD3lsgZ4xvm5k0G8XfvMgOOTQzj+BSF2pMmlWTZm0C1mmKU1OL9KUCu5?= =?iso-8859-1?Q?1liax6A2jIVpkk5516grHLjdK22yinwcfG2fXuqhjar1HQ3N4Lvr96fPDF?= =?iso-8859-1?Q?TgvP9Yoa96il7gBy6qspF0uEhMXqvtGqKNWIzbVC2YfVDsXLH3ZmRDobwd?= =?iso-8859-1?Q?sV9MChV9AwQPK8hGMUaHebS6jYJubtlgNlYGJJukkg6nczIJFtoJjARD5n?= =?iso-8859-1?Q?TgTXVWMpVc3CTxiqFn18iCLjlPhPwROvl1jDd28VxWpoE3H3lNgrmGJpT2?= =?iso-8859-1?Q?bLG6zCv8uz6KzuxKP1T5y83pyaQLm+LiptrdXbmPweOlLkt8/lwFstSkWd?= =?iso-8859-1?Q?sapjLiVSUxJua+F9DDb8/H6nAZtMSyhBcWAtOB8ukHHILa8qY4Q3mY+xrS?= =?iso-8859-1?Q?dI+lnnKakRmyUXQ5Qq6UrlYLz8VCxFqLRc/Bqbu8dDhweIrEdkGkuAvddM?= =?iso-8859-1?Q?T7uIbT/bSx1V5wdGDVta5QHGIaew7ubwIR9d68BukGi9/+boJq4qB2wMcD?= =?iso-8859-1?Q?M+Zi8YrgT4saGd3K8fJt4?=
X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB353; 3:9tuDe248Whd8iGgQ0DMhMg1hxNCax5yJSvI0eOON2Urm1oKS4/McW7sgS9VA+pORy2HMbhyUgTLlGGxfr5DpTShX+57gJfOwruvGMiHfJ0RVUmwocEm3nptXpXikxuUYLWCy7CN1iYOMRSGJNwI7mg==; 10:KXRNkxcSR0Jx6a8IFB7x1EfQL3pIamafR27xMaNvG/+gTxx6XCOzVEEBEF59Ngkd9zc/LJ3GHZq6iwIYjcCECkVW2YyDoNVp0mvi7tUWQv8=; 6:/Z0Mgl7YPVuuWifuABkuQNqi+5w/bUhi6WpuF8j+0aBnzLNM3DLi68Vri16up+NZ
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2015 23:35:59.3679 (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: BL2PR03MB353
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/w225mpazEpub9flvc0UmlWDvsMA>
Cc: Florian Weimer <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: Fri, 22 May 2015 23:36:26 -0000

Hi Kurt,

> > (http://www.mitls.org/).
>
> I was unable to get it to build (using free software).

I've just succeeded building mTLS-0.8.1 using Mono 3.10.0.0. I haven't tried
Mono 4 or .NET core (MIT license). You can send me a private mail if you want me
to help you troubleshoot.

> > If the modulus is prime but not safe, miTLS
> > checks if it is in the table of trusted parameters and otherwise
> > rejects it.
>  
> When is it non-safe but trusted?

When it is in the table of trusted parameters, and hence we know the subgroup order
(the prime q in DSA terminology). Just to avoid misunderstandings, we clarified
the formal meaning of "non-safe" earlier in this thread.

> > I think a table lookup per key exchange is about as reasonable as it
> > gets.
>  
> I assume that's a table lookup in case it hasn't seen that prime
> yet?  

It's a table lookup when it *has* seen the prime before.

> But I understand that they're recommending everybody to generate their own
> prime.

I believe large >=2048 bits fixed primes, like the ones proposed in the
negotiated-ff-dhe draft, are fine for the time being. See Karthik's message on
this same thread which better clarifies what our recommendations are.

--Santiago

________________________________________
From: Kurt Roeckx <kurt@roeckx.be>;
Sent: Friday, May 22, 2015 6:56 PM
To: Santiago Zanella-Beguelin
Cc: Nikos Mavrogiannopoulos; Florian Weimer; tls@ietf.org
Subject: Re: [TLS] Another IRINA bug in TLS

On Thu, May 21, 2015 at 02:52:47PM +0000, Santiago Zanella-Beguelin wrote:
> Regarding validation of DHE parameters and how reasonable it is in
> practice, I wanted to make some publicity for miTLS
> (http://www.mitls.org/).

I was unable to get it to build (using free software).

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

When is it non-safe but trusted?

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

I assume that's a table lookup in case it hasn't seen that prime
yet?  But I understand that they're recommending everybody to
generate their own prime.


Kurt