Re: [TLS] draft on new TLS key exchange

[Marsh Ray <[e-mail]>]

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