Re: [TLS] Another IRINA bug in TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 24 May 2015 07:12 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 5A0851A87AD for <tls@ietfa.amsl.com>; Sun, 24 May 2015 00:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 HM5tYYPh2DTA for <tls@ietfa.amsl.com>; Sun, 24 May 2015 00:12:03 -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 A8DD31A879A for <tls@ietf.org>; Sun, 24 May 2015 00:12:02 -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=1432451522; x=1463987522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+rj/CRoSt/DzC9PpHHTBVKUfuTKdWUqjmIvVFzFxNA8=; b=oCE1aRUX790rTC87/B+OevIFEsKuck9J8Ut9Pg+se2F2dNTDQ5H99ugn MkSg90U8osy2aGKj89uPLpYr02+hOKTZ83Rs/80QQadqQYdcWGmToQcV7 JMlTiNu7koigaICIno4hM8j1gl2rOuI6+dZqFPkO+O4hLIyOlRoBIpT/r fQ2QVM+1hmRPDJKVeBdvjruQ7qxtyLw3MyUYqYYDx6UZAO2W/Qs390Pez xPot9S8qcT4n5kRHuniBit8gBZ/Yz2POJcQX81gNKnDa0uoCNtFk3Vfo6 iSTbVDwtPPcp6a3+O0BvGIzTFMg9jF7Sw38MdQrWKvJau1IX0mZSrfHVO w==;
X-IronPort-AV: E=Sophos;i="5.13,485,1427713200"; d="scan'208";a="17936067"
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; 24 May 2015 19:12:01 +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; Sun, 24 May 2015 19:12:01 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "noloader@gmail.com" <noloader@gmail.com>
Thread-Topic: [TLS] Another IRINA bug in TLS
Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8P//W1SAgANHxkA=
Date: Sun, 24 May 2015 07:12:00 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <CAH8yC8=F3jJgEzFQSN=ZMvoC4zunAsfHPs1k2km9dvFJ0bvg2g@mail.gmail.com>
In-Reply-To: <CAH8yC8=F3jJgEzFQSN=ZMvoC4zunAsfHPs1k2km9dvFJ0bvg2g@mail.gmail.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/ZDmpCqRKCms9FUJhSysDCra6usQ>
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: Sun, 24 May 2015 07:12:08 -0000

Jeffrey Walton <noloader@gmail.com>; writes:

>GnuTLS with its Lim-Lee primes causes me a lot of problems because they
>cannot be validated.

Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as well!), it's
the fact that TLS uses the PKCS #3 format rather than the DSA format, so
you've got nice verifiable values for which you have to throw away the
parameter used to verify them and send them in an unverifiable format.  Having
said that, there's a pretty simple fix, define an extension that acts like the
existing propose/accept extensions that signals a change in DH values to the
DSA form (p, q, g) rather than PKCS #3 form (p, g).  And for TLS 1.3, use the
DSA form by default, not the PKCS #3 form.

Peter.