Subject: [TLS] about the PWD Proposal

From: [email-masked]
Date: Fri, 18 Nov 2011 16:59:07 +0800

Hi,
 I am interested in the PWD proposal at the meeting, and run through 
it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4),
 and have the following concerns:

1. In the document, it  says both Client and Server should be able to 
compute PE, which is derived from username, password, salt,etc.
   That means Client or the user should also remember the salt value, in 
that case, salt is meaningless and can be replaced by a longer password.
   This is quite different from the widely known usage of salt, e.g. in 
UNIX operating system, salt is not required to remember by the user, but 
by server to fetch locally by reference to the username. 
  And as far as I know, I am sure the authors also know that, other 
password based key exchanges protocols don't involve salt, but store a 
hash value of password among other things locally.
2. From the figure in the PPT shown at the meeting, I cann't see why the 
protocol should use both "private" and "mask" values, in my opinion, only 
"mask " value shall be OK.
   private value is redundent, and not helpful in security improvement.
   because the current derived shared key is PE^{private_a*private_b} 
according to this document， and
   after removing private value, it will be  PE^{mask_a*mask_b}
   and private, mask value are both generated locally and not transported 
on the wire, so it does not make much difference except making it more 
complex.
3. Now I only talk about the security of the simplified version (as in 
above point 2)
   after simplification the protocol is easier to analysize, it is just 
like an ordinary DH exchange except that the base group generator is PE 
instead of g.
   So the security is reduced to the PE, is it a good group generator 
which has large order? if not then it is insecure.
   Unfortunatly the authors failed to analysize this crucial point.

Thank you for your patience!

Sujing Zhou 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2011 12:46:45 +0200

Hi

On Nov 18, 2011, at 9:59 AM, <[email-masked]> <[email-masked]> wrote:

> 
> Hi, 
>  I am interested in the PWD proposal at the meeting, and run through it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), 
> 1. In the document, it  says both Client and Server should be able to compute PE, which is derived from username, password, salt,etc. 
>    That means Client or the user should also remember the salt value, in that case, salt is meaningless and can be replaced by a longer password. 
>    This is quite different from the widely known usage of salt, e.g. in UNIX operating system, salt is not required to remember by the user, but by server to fetch locally by reference to the username. 
>   And as far as I know, I am sure the authors also know that, other password based key exchanges protocols don't involve salt, but store a hash value of password among other things locally. 

I realize that this is very different from the usage in UNIX operating systems, but it is necessary, as the UNIX (or other) operating system running the web server has to store the password. Storing the password in the clear on as an unsalted hash is worse than storing a salted hash (or "base" in the draft's terminology), so that is what the TLS server does. The use of base instead of password is not to protect the password during handshake, but to protect it during storage on the server.

Having said that, I think it is now very practical to take a list of the 100,000 most popular passwords on the web, a database of 10,000 salted hashes (the file described in section 3.4), and find all the matches. That's 1,000,000,000 operations, which would take 15 minutes on a MacBook Air (1.4 GHz). I think the days of saying that a database of salted hashes makes theft of the password file irrelevant should be over. Yes, I know that with unsalted hash it would be practical to test the 100,000,000 most popular passwords. 

<snip/>
> Sujing Zhou   

One more thing: I realize that the above line was probably inserted either by your MUA or MTA, but it is not true. Email messages to IETF mailing lists are considered contributions, and are subject to "Note Well" http://www.ietf.org/about/note-well.html

Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 19 Nov 2011 12:13:23 -0800 (PST)

Hello,

>  and have the following concerns:

  Thank you for your interest.

> hash value of password among other things locally.

  As Yoav mentioned, the salt is used to protect against server
compromise. If the salt is chosen randomly by the server (as it should
be) then an adversary who obtains possession of the database of salted
passwords is required to effectively do an off-line dictionary attack
against each entry in the database to recover passwords.

  The salt is not stored by the client, it is communicated to the client
in the ServerKeyExchange. All the client needs to do is remember the
password.

> according to this document£¬ and

  The private value is used in the final exponentiation (or, equivalently,
point multiplication) to derive the pre-master secret. Each private
value is sent to the peer masked by modulo addition (which means that a
passive attacker cannot guess the private since there are q different
pairs of numbers that sum to any given number less than q and a
probability of 1/q is effectively the same as guessing a DH exponential
which we all assume is too hard). The mask is removed through modular
multiplication (or equivalently, point addition) in a manner that prevents
the disclosure of the private value.

  Private is definitely not redundant!

>    Unfortunatly the authors failed to analysize this crucial point.

  An ordinary DH with PE as the generator is the SPEKE exchange. This
is decidedly NOT an ordinary DH with PE as the generator. As mentioned
above, both mask and private are crucial and such a "masked" exchange is
not ordinary, PE as the generator notwithstanding.

  Please look at the exchange again in more detail.

> Thank you for your patience!

  Thank you, again, for your interest! Perhaps you can implement it. :-)

  regards,

  Dan.