Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

"Dan Harkins" <dharkins@lounge.org> Thu, 28 November 2013 06:49 UTC

Return-Path: <dharkins@lounge.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 7368D1AE13F for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 22:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 hBdc_dz7lwjR for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 22:49:05 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D5F921AE10B for <tls@ietf.org>; Wed, 27 Nov 2013 22:49:05 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B4B4010224008; Wed, 27 Nov 2013 22:49:04 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 27 Nov 2013 22:49:05 -0800 (PST)
Message-ID: <3f9cc03f542291ac17e0d173c09d0177.squirrel@www.trepanning.net>
In-Reply-To: <CADMpkc+ArvpCA5rpqhSGH8WmV3AsPMsL6ZMf0r2-UeHR=jOjug@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com> <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com> <e2d8d4a17842e828a3325665a2e5e348.squirrel@www.trepanning.net> <CADMpkc+ArvpCA5rpqhSGH8WmV3AsPMsL6ZMf0r2-UeHR=jOjug@mail.gmail.com>
Date: Wed, 27 Nov 2013 22:49:05 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Bodo Moeller <bmoeller@acm.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Thu, 28 Nov 2013 06:49:07 -0000

On Wed, November 27, 2013 2:31 pm, Bodo Moeller wrote:
> Dan Harkins:
>
>>   That said, the issue you bring up remains since it is also possible to
>> just send the complete domain parameter set. But this is how TLS handles
>> discrete logarithm-style cryptographic parameter negotiation. So this
>> issue applies to every TLS cipher suite that provides for some kind of
>> exchange using discrete logarithm cryptography, including all of the
>> ones with DH in the key exchange-- i.e. DHE, ECDH, ECDHE, etc. This
>> "full flexibility" issue sounds more like something for TLSv1.3  than
>> for
>> TLS-pwd.
>
> While parameter negotiation does look like that for TLS DHE ciphersuites,
> that's actually a very different issue, because there these groups are
> used
> differently: either parameters are authenticated (signed by the server's
> public key from the server cert) or the server is entirely anonymous.
> This
> is very different from relying on initially unauthenticated parameters for
> a password-authenticated key exchange, where the security issues that I
> described come up.

  I'm not sure how using a cipher suite with an anonymous (i.e.
unauthenticated) server is "very different from relying on initially
unauthenticated parameters" since with an unauthenticated server
the parameters will not only be initially unauthenticated but always
unauthenticated.

  Regardless though, what you said was that TLS-pwd was susceptible to
a "trapdoor prime" attack and you provided a link describing it in regards
to TLS-SRP,  and you described it thusly:

"Not all safe primes are created equal -- a malicious server might
compel the client into performing the SRP protocol where N is a
'trapdoor prime', a prime that has been specifically chosen to make
the computation of discrete logarithms feasible."

And that is not possible with TLS-pwd because the client presents the
set of domain parameter sets and the server picks one. The server does
not dictate the acceptable domain parameter set(s) with TLS-pwd. This
sort of attack where a malicious server forces a client into using a
domain parameter set it did not offer is not really possible. And any
man-in-the-middle that mucked with a ClientHello to force the
exchange into some domain parameter set it wants would be detected
when checking the Finished message and the exchange would fail.

  It's interesting that the fix you suggest for this problem-- "The proper
fix is to allow just a certain fixed (standardized) set of parameters" --
is what TLS-pwd already does.

  Dan.