Dave Cridland wrote:
> On Fri Mar 6 14:42:50 2009, Eric Rescorla wrote:
>> You MITM the initial connection, then wait for one side to offer his
>> proof. You then simulate a failure, crack the password, and move
>> on. Note that if the password is short enough, you can crack it in
>> real time and move on.
>
> Right, I see.
>
> Surely if I'm talking to Peter, and arrange a shared secret, and then
> I find Peter rejects it, I'm going to tell him pretty quickly? I
> accept it's possible to circumvent, and there'll be issues with
> hardware doing this, though.
You won;t see a rejection if the MITM in the TLS connection(s) is the
same MITM that can change Jingle stanzas. So the server can do bad
things. And the idea behind e2e (at least in my scenario) is that you
don't trust the server.
> This is certainly going to be harder to deal with - the 4-digit pins
> are really related to hardware and other such dumb devices. I'd guess
> that with SRP, the timescales are simply going to be a bit longer,
> though?
I talked to Thomas Wu, the author of SRP, and he confirms that SRP is
secure even for short pins.
In the ServerKeyExchange message, the server "commits" its knowledge
of the password verifier, while the client does so in its Finished
message. The server's Finished message confirms to the client that
the server really knows the premaster secret and by extension, the
password verifier. This is why the ordering of the Finshed messages
is also important in the SRP ciphersuites.
This means that the server must know the password in the second phase of
the handshake, but sends only a hash of the password and a random
value. No way for the client to guess it. The client sends the Finished
message which is encrypted with the premaster key which is based on the
password. The client only has one shot to get the password right. After
that, the server proves that it has the password in its Finished
message. No way to guess it based on the client's message because it has
to match the information it send in its first message.
I hope I got this wrong. This is how I understood it after reading
TLS-SRP, SRP, and talked to Thomas. So for TLS-SRP both clients must
know the password and have no way of getting it with brute force. They
only have one change and if the passowrd does not match, TLS setup will
fail. And a client should not allow 10000 attempts to open the TLS
connection.
Dirk
--
In which level of metalanguage are you now speaking?
