Re: [TLS] draft on new TLS key exchange
Marsh Ray <marsh@extendedsubset.com> Thu, 06 October 2011 17:56 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 1F55521F8CF7 for <tls@ietfa.amsl.com>; Thu, 6 Oct 2011 10:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 sxK7N-qDWuWC for <tls@ietfa.amsl.com>; Thu, 6 Oct 2011 10:56:42 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6821F8CEC for <tls@ietf.org>; Thu, 6 Oct 2011 10:56:41 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1RBsEa-00020j-UP; Thu, 06 Oct 2011 17:59:53 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 6696563BF; Thu, 6 Oct 2011 17:59:51 +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: U2FsdGVkX19SeVfjgwhrywS/7N20jj+QZTIEj3nA2Wg=
Message-ID: <4E8DEC96.5000508@extendedsubset.com>
Date: Thu, 06 Oct 2011 12:59:50 -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: Dan Harkins <dharkins@lounge.org>
References: <ce78cf414ed82d44135ebbb88e32959b.squirrel@www.trepanning.net> <4E8D5198.4020809@extendedsubset.com> <63ad01d6fca38d4d44979254d6b48178.squirrel@www.trepanning.net>
In-Reply-To: <63ad01d6fca38d4d44979254d6b48178.squirrel@www.trepanning.net>
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 17:56:46 -0000
On 10/06/2011 11:38 AM, Dan Harkins wrote: > > The client definitely authenticates the server. They both perform the > same calculations to arrive at the same premaster secret. If either side > has the wrong password, the secret group element will be different and > they'll be doing their calculations with a different generator and > that won't work. But that's not exactly the same as the client authenticating the server. That's the client authenticating that "the server endpoint knows the password for the username I supplied", the server name and port are not bound into the authentication anywhere. There's an implied assumption that only the intended server would know the password, but this assumption is not reliable in practice. IMHO this does not constitute strong authentication of the server to the client. >> Comment 2: >> >> But the server DNS name and port do not appear to be bound into the >> authentication. Couldn't the bad guy take a connection destined for one >> web site/service and feed it to another? > > Only if that other website had provisioned the same username/password. This is a common case and the security properties differ dramatically in this regard from most existing uses of TLS. So it probably should be discussed in the security considerations section. >> Is there any way to impose a work factor onto the attacker's guesses? > > As I mentioned in a previous email it's possible to salt the password > at provisioning time and have the server send the salt to the client in > the ServerKeyExchange. I will do that in -01. I think people will be looking for bcrypt, scrypt, or PBKDF2 with some SHA > 1. They will want to choose the work factor. >> Who do you envision will deploy a protocol that requires the storage of >> plaintext passwords? > > That sounds like a general, non-TLS-specific, question so I'll answer > it generally: when either side can initiate to the other, or in a true > peer-to-peer situation where both sides could theoretically initiate > simultaneously. But that's not the case for TLS where there are strict > client and server roles. http://tools.ietf.org/html/rfc2246 > client > The application entity that initiates a TLS connection to a > server. This may or may not imply that the client initiated the > underlying transport connection. The primary operational > difference between the server and client is that the server is > generally authenticated, while the client is only optionally > authenticated. Those roles are not actually so strict, and this proposal seems to sort of reverse the primary direction of authentication compared to existing uses of TLS. Could be useful, but deserves to be stated explicitly. >> 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? > > This is a very good point. I think the attacker would have to observe > successful handshakes though. It's the number of times through the loop > until the PE is determined that the attacker wants to know and a failed > guess will not provide any useful information. Won't at least one of the attacked endpoints still be working from the correct password? Won't his timing be enough? > And I don't think this attack enables an offline dictionary attack. > I think that it will allow the attacker to exclude large chunks of the > password pool with each observed successful exchange until what's left > is manageable (or until there's just 1 entry left in the pool). That probably would be more sophisticated, but he could probably also just run through the 10000 most common passwords and see which ones fit the observed timings. A busy server is going to have orders of magnitude more TLS handshakes than users over any reasonable period of time. > But I'm not sure how concerned I am about this. After finding PE > there will be a modular exponentiation or point multiply using this > random element as the generator. That's a random generator and a random > scalar and the timing variablities on that will make it hard to isolate > the timing dependencies of the hunting-and-pecking loop. Especially > since it's a random PE used for each run of the protocol. But if it's perfectly random (or at least doesn't correlate to the number of iterations) then all that averages out quite nicely. It's simply a question of how many samples are needed. > Combine that > with the system knowledge and control required to glean timing information > out of an observed run of the protocol and I'm not sure how practical > this would be. Famous last words. - 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