Re: [TLS] Another IRINA bug in TLS

Andrey Jivsov <crypto@brainhub.org> Sun, 24 May 2015 17:21 UTC

Return-Path: <crypto@brainhub.org>
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 A74621AC412 for <tls@ietfa.amsl.com>; Sun, 24 May 2015 10:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no
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 EadB3UnvjJVX for <tls@ietfa.amsl.com>; Sun, 24 May 2015 10:21:49 -0700 (PDT)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFF81AC402 for <tls@ietf.org>; Sun, 24 May 2015 10:21:49 -0700 (PDT)
Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-09v.sys.comcast.net with comcast id XtMm1q00254zqzk01tMooM; Sun, 24 May 2015 17:21:48 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-11v.sys.comcast.net with comcast id XtMn1q00L4uhcbK01tMnbg; Sun, 24 May 2015 17:21:48 +0000
Message-ID: <556208AB.2040009@brainhub.org>
Date: Sun, 24 May 2015 10:21:47 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <1432317148442.5357@microsoft.com>, <9A043F3CF02CD34C8E74AC1594475C73AB02AC90@uxcn10-tdc05.UoA.auckland.ac.nz> <1432472352214.2674@microsoft.com>
In-Reply-To: <1432472352214.2674@microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1432488108; bh=OD/4VGvGyhqin9MCVk8J8FqPjZ9tBHxMtdZ7jUucQOk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h5aJbrhBTsb1oM2XBCf9rR18h0GnviQkMV2zyleNHJlhBQlzelI/njdk1d+fP6UDj 7N7RbMFwBounmD5ZK9BRejuxYLSz60VcQLh7dRtt4CJ0TPSfOjDuLBz8J+/59aP6/e JSt/i1HDA2IauEWdlSZBQj9RME0zgLWFjzsSQ+C1yOguZlLAZpGLMfv4aikp4zve93 RW3yBOp1X+KZjg0liy5IFaBZsN548py97+j1JAF5i0s6+JOFj9d7GGhgmMM2VpNeTf sE8wlZmqGiGQp2bqoJK3diYiYxGiMjJqjYN/6ttmhoRRucQTSKgvHEWqb+LtVYrJym LyPt3A1BzNylw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FGfZ_JmsqANPwC4p8NnVSirjKwU>
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: Sun, 24 May 2015 17:21:51 -0000

On 05/24/2015 05:59 AM, Santiago Zanella-Beguelin wrote:
>> Just out of interest and if you have any sort of figures, what sort of
>> rejection rate do you get, and what sort of distribution do you see for g=2
>> vs. g=anything else?
> Sorry, we don't have that sort of telemetry.
>
>> I've seen a lot of g=2, then some g <= 8 bits, and a
>> very few sizeof( g ) == sizeof( p ) which I suspect is the q vs. g confusion
>> mentioned elsewhere
> For DSA parameters, sizeof(g) == sizeof(p) is what's expected. Rather,
> sizeof(g) == sizeof(q) would be very suspicious.

sizeof(g) ~= sizeof(p) would be expected if one to follow the DSA spec. There are two methods specified, including deterministic/verifiable generation, both resulting in this outcome.

See http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf, sec A.2.1, A.2.3

Interestingly, the g validity check in sec A.2.2 may allow small g (except in the case of a verifiable g).

You probably didn't mean strict size checking, but let me note it anyway. Strict checking sizeof( g ) == sizeof( p ) for DSA will result in hard-to-reproduce interoperability failures, which are bugs. Given how the FIPS 186-4 is specified, it's unreasonable to demand ==.

>
>> (looking at dh_check.c, I see that it comments out the
>> check for g=3, implying perhaps that it's not seen in the wild?).
> Are you talking about OpenSSL? I don't know what it checks.
>
>> However because I typically don't have direct contact with, or control over, end
>> users, only developers building end-user products, in my case any check with a
>> FP rate greater than zero is going to cause headaches.  Even something as
>> simple as rejecting obviously bogus g values (which is what the broken PLC
>> I've mentioned previously does, among assorted other bugs) causes problems
>> because what matters is availability, not correct use of DH values (or correct
>> implementation of the TLS protocol).
> Then I'm afraid I cannot help you. What matters to me the most is
> security, not being able to interoperate with servers using buggy
> parameters or insecure implementations of TLS.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls