Re: [TLS] draft on new TLS key exchange

Martin Rex <mrex@sap.com> Fri, 07 October 2011 17:55 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89F821F85B5 for <tls@ietfa.amsl.com>; Fri, 7 Oct 2011 10:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.074
X-Spam-Level:
X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZzFyZk83XsR for <tls@ietfa.amsl.com>; Fri, 7 Oct 2011 10:55:45 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 31BF721F8C0E for <tls@ietf.org>; Fri, 7 Oct 2011 10:55:44 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p97HwoH9017253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2011 19:58:55 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201110071758.p97HwniX022621@fs4113.wdf.sap.corp>
To: dharkins@lounge.org
Date: Fri, 07 Oct 2011 19:58:49 +0200
In-Reply-To: <8d93ad0b8c3b53995c28a38cf8c6bf3e.squirrel@www.trepanning.net> from "Dan Harkins" at Oct 6, 11 02:03:14 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org, dhalasz@intwineenergy.com
Subject: Re: [TLS] draft on new TLS key exchange
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 07 Oct 2011 17:55:46 -0000

Dan Harkins wrote:
> 
> The relation-- yours is "faster" than the unknown one-- means nothing.
> That knowledge doesn't help. Knowing how many iterations the hunting-
> and-pecking loop went through to find PE for an unknown password might
> but the relationship between two means nothing.  In fact, since both
> sides are contributing randomness into the hunting-and-pecking loop
> yours might be "faster" one time and considerably slower the next time.
> That knowledge doesn't really help.

The number of iterations for the hunting and pecking is visible in the
timing unless a reliable response time blending is employed (which would
have to account for an attacker running multiple requests in parallel to
slow down server-side processing).

Although both sides contribute randomness into the process, the only
unknown in the low-entropy password, everything else is revealed.
Since it is revealed, the attacker can use the timing "distance"
between processing his own password and processing guessed passwords
with the EXACT same parameters to sort out unlikely candidates.

-Martin