Re: [TLS] Another IRINA bug in TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 24 May 2015 12:37 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 3026D1A8ACA for <tls@ietfa.amsl.com>; Sun, 24 May 2015 05:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_18=0.6, T_RP_MATCHES_RCVD=-0.01] 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 SmauNdoyifP1 for <tls@ietfa.amsl.com>; Sun, 24 May 2015 05:37:08 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D131A8ACB for <tls@ietf.org>; Sun, 24 May 2015 05:37:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1432471027; x=1464007027; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IJQLao/fNfOswD5qJI3W67VcXUQOFuII7rQDuQ1Q/ss=; b=2MbfTV9ZKmFfh41Kx3iOPIdysYx27VpGvAEmx3C/4e76gF6aT7U/YEL4 xmOc/b5Rw27MkCHHRWOrursiQotYhJQiOcBFaStGNjTLG6ABFrFeCSypv OhAKPYGRiPaGl3PKPKxCoc4wa0HwaXzDchDkGSB6gg3WJMQYmsaO6kQ9S HHoFSs1zIMKrY6DSJg/DQ/2phGSRXpKoXF+sAuqYmc8U7Hs1zY9c49E1P jTGomCWORedlLksWrZjXIca8YVad5u2A5MF3zMOniP3af964vs0N9Bnpg Dhea4Wm9P1RMgBgUMc5EZpBuDT7IAcIBk9nx1kJIEsBHeocGYDrlkqFu7 w==;
X-IronPort-AV: E=Sophos;i="5.13,486,1427713200"; d="scan'208";a="18010978"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 May 2015 00:37:06 +1200
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Mon, 25 May 2015 00:37:06 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Santiago Zanella-Beguelin <santiago@microsoft.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8P//aHSAgAOVT2A=
Date: Sun, 24 May 2015 12:37:06 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02AC90@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <1432317148442.5357@microsoft.com>
In-Reply-To: <1432317148442.5357@microsoft.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3ULpIQOexzYMO53vxFV-_EtGtoc>
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 12:37:12 -0000

Santiago Zanella-Beguelin <santiago@microsoft.com>; writes:

>We accept them if they're in the pre-populated cache. If not, we reject them
>because we can't check the order of the generator and validate ephemeral keys.

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?  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 (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?).  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).

Peter.