Re: [TLS] draft on new TLS key exchange
Marsh Ray <marsh@extendedsubset.com> Thu, 06 October 2011 20:22 UTC
Return-Path: <marsh@extendedsubset.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 BAEB321F8E1B for <tls@ietfa.amsl.com>; Thu, 6 Oct 2011 13:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599]
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 f6pVitbL0lcA for <tls@ietfa.amsl.com>; Thu, 6 Oct 2011 13:22:51 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1A21F8E0A for <tls@ietf.org>; Thu, 6 Oct 2011 13:22:51 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1RBuW2-00043l-EG; Thu, 06 Oct 2011 20:26:02 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AB32063BF; Thu, 6 Oct 2011 20:26:00 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19yTWxndkCs8upEW68MOnX+JzhSPPjARTk=
Message-ID: <4E8E0ED7.80705@extendedsubset.com>
Date: Thu, 06 Oct 2011 15:25:59 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: mrex@sap.com
References: <201110061906.p96J6qKa003260@fs4113.wdf.sap.corp>
In-Reply-To: <201110061906.p96J6qKa003260@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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
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, 06 Oct 2011 20:22:51 -0000
On 10/06/2011 02:06 PM, Martin Rex wrote: >> >> Marsh Ray wrote: >>> >>> Couldn't an attacker observe the timings of a sufficient number of >>> failed handshakes to enable an offline brute force attack on the >>> low-entropy password? > > I agree with Marsh, it is difficult to conceive how to implement > this without being a timing oracle. I disagree with Martin. :-) It probably could be implemented without being a timing oracle, but blinding the timing channel might impose something approximating worst-case latency in all cases. Without benchmarking, I don't know if that means microseconds or milliseconds. But mainly the fix wouldn't happen by accident. It needs to be pointed out with a high profile in the security considerations section. > The question is, how much does it help you. > > If you already have an account or could create one, then the timing > would help you sort out unlikely passwords, I assume, because you > know the algorithm and can determine "off-line" whether a computation > for a newly guessed password is faster or slower than your own password > and you can measure the servers response times for your password and > for the unknown password and therefore know their relation. Collect timing on a few thousand handshakes for a given user. Observe the server response time clustering into buckets with a log_2 decaying distribution. > I don't find it very attractive if an authentication protocol gives > an attacker a huge advantage at guessing an unknown account credential > if he can create or obtain a valid account credential. I don't think it requires the attacker to obtain an account on the same server (but even if it did, that would still be bad). > I also feel very uncomforable with the extremely vague term > "low-entropy password" and the idea that this could be secure. Sometimes we have to make the best of what we've got. Maybe sometimes all we've got is a password. Still, I'm skeptical about who would use this thing and that they wouldn't be better served with something else. > If the whole handshake takes 1 second to complete (or fail), then > a brute force of the entire 2^13.28 entropy universe completes > in less than 3 hours. Without a lockout, there just is not any > meaningful security possible. Consider a "smart grid" of electric meters with a service lifetime of 30 years. The meters probably have very slow CPUs making timing values relatively large and easy to distinguish. They may handshake regularly with the controlling systems. The power line network is about as open and undefended as you can get. An attacker may be able to gather timing statistics for several years, after which he has obtained complete "blinkenlights capability" over the service region. That would be bad. - Marsh
- [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Geoffrey Keating
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Jean-Marc Desperrier
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Yoav Nir
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Martin Rex
- [TLS] TLS-EAP. Was: draft on new TLS key exchange Anders Rundgren
- Re: [TLS] TLS-EAP. Was: draft on new TLS key exch… Marsh Ray
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Philip Gladstone
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Jean-Marc Desperrier
- Re: [TLS] draft on new TLS key exchange Martin Rex
- Re: [TLS] draft on new TLS key exchange Rene Struik
- Re: [TLS] draft on new TLS key exchange Nico Williams
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Nico Williams
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Steven Bellovin
- Re: [TLS] draft on new TLS key exchange Anders Rundgren
- Re: [TLS] draft on new TLS key exchange Steven Bellovin