Re: [TLS] draft on new TLS key exchange

[Marsh Ray <[e-mail]>]

On 10/05/2011 01:12 AM, Dan Harkins wrote:
>
>    Hi,
>
>    I just uploaded a -00 draft that defines a new key exchange
> for TLS that does not require certificates-- authentication using
> a simple password only. It can be found at:
>
>           http://tools.ietf.org/html/draft-harkins-tls-pwd-00
>
>    Please take a look. The authors solicit comments.

http://tools.ietf.org/html/draft-harkins-tls-pwd-00 :
> 4.  Specification of the TLS-PWD Handshake
>
>    The authenticated key exchange is accomplished by each side deriving
>    a password-based element, PE, in the chosen group, making a
>    "committment" to a single guess of the password using PE, and
>    generating the Premaster Secret.  The ability of each side to produce
>    a valid finished message authenticates itself to the other side.

Here are my comments. Some of them probably apply to other TLS 
password-only schemes too.

Comment 1:

Are you familiar with the studies showing that the great majority of 
users re-use passwords across sites and a large percentage have same 
password everywhere?

http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html
http://nakedsecurity.sophos.com/2009/03/10/password-website/

This one finds that the average password is used at 6 different sites:
http://research.microsoft.com/apps/pubs/?id=74164

I don't see anything in this protocol that allows the client endpoint to 
actually authenticate the server. Can the client know if he's 
authenticating with the legitimate server?

If not, perhaps it's OK as long as either the handshake fails or the bad 
guy is reduced to the role of a dumb router between the legit client and 
server.


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?

Comment 3:

The standard of practice for actual "secure" web sites (e.g. PCI 
compliance if you want to handle credit cards) forbids storing plaintext 
passwords on the server side. Any web app developer who was not using at 
least salted hashes today would be ridiculed as incompetent (e.g., 
Sony). The industry seems to be recognizing the importance of imposing a 
work factor (PBKDF2, bcrypt, scrypt) to resist dictionary attacks when 
the authentication database gets compromised, say, by a typical SQL 
injection.

Is there any way to impose a work factor onto the attacker's guesses?

Who do you envision will deploy a protocol that requires the storage of 
plaintext passwords?

Conceivably there could be special-purpose systems that could generate 
handle these passwords securely, but couldn't they just as easily manage 
a private cert infrastructure?

Comment 4:

The hunting and pecking loops for both the ECC and FFC password elements 
look like a timing oracle to me. They seem to require a large 
exponentiation or sqrt on every iteration and the number of iterations 
is data-dependent. If I'm not mistaken, every input to the loop except 
the password itself is transmitted in cleartext during the handshake.

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?

- Marsh