Re: [TLS] Another IRINA bug in TLS

Andrey Jivsov <> Sun, 24 May 2015 17:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A74621AC412 for <>; Sun, 24 May 2015 10:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.099
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EadB3UnvjJVX for <>; Sun, 24 May 2015 10:21:49 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 8EFF81AC402 for <>; Sun, 24 May 2015 10:21:49 -0700 (PDT)
Received: from ([]) by with comcast id XtMm1q00254zqzk01tMooM; Sun, 24 May 2015 17:21:48 +0000
Received: from [] ([]) by with comcast id XtMn1q00L4uhcbK01tMnbg; Sun, 24 May 2015 17:21:48 +0000
Message-ID: <>
Date: Sun, 24 May 2015 10:21:47 -0700
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <>, <>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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: <>
Subject: Re: [TLS] Another IRINA bug in TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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, 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