Re: [TLS] PSK in 1.3?

[Stephen Checkoway <[e-mail]>]

On Feb 23, 2015, at 9:33 PM, Dan Harkins <[e-mail]> wrote:

> I'm saying that since the security of the protocol depends on it being
> used right, _the protocol_ cannot be said to be secure.

Every security protocol's security depends on it being used correctly. That doesn't seem like a useful metric here.

> 
>> I don't see how to square that with Bellare-Pointcheval-Rogaway's
>> definitions (which I think is what you're using as your definition of
>> security). You write,
>> 
>>> Namely, "In a protocol we deem 'good' the adversary's chance to defeat
>>> protocol goals will depend on how much she interacts with protocol
>>> participants-- it won't significantly depend on her off-line computing
>>> time." By that criteria, TLS-PSK is not good.
>> 
>> But that seems to misunderstand the quoted sentence. It's the adversaries
>> chance to defeat the protocol goals which is deemed to be good, not the
>> protocol itself. More to the point, the security of a protocol is defined
>> in terms of an adversary running in time t and making q queries. If the
>> passwords are drawn from a space of size N, then the fact that an
>> adversary which runs in time N or makes N queries can have advantage 1
>> doesn't really tell us anything. See, for example, Theorem 1 of the BPR
>> paper. If q_se = N, then the advantage is bounded by 1, but of course it
>> is. That doesn't make the protocol under consideration insecure due to
>> dictionary attacks. Indeed, see remark 9 just below noting that making N
>> larger makes dictionary attacks moot.
> 
>  No, I don't think you understand the quoted sentence.  Note how they say,
> "In a protocol we deem 'good'…" That right there means they're talking about
> the protocol being good or not, and not the adversary's chance to defeat
> protocol goals.

You may be right. I was mentally inserting a comma after "in a protocol" whereas you are inserting one after "good." But my reading doesn't fit with the rest of the sentence. My mistake.

> The adversary's chance of defeating protocol goals will grow
> (by exploiting the flaw in all protocols that authenticate using a symmetric
> key/code/word/phrase), it's a matter of how.

I don't think this is a matter of using a symmetric key/code/word/phrase at all. You have exactly the same problem using DHE. I can enumerate (in theory) the space of secret keys until I find one with a corresponding public key that appears in the TLS handshake. Now I've recovered the shared secret and I've done it with zero interaction with the protocol, purely offline computation.

> The _protocol_ is deemed
> "good" if the adversary's advantage grows as a function of computing, not
> as a function of interaction with protocol participants.

Wait, now you're saying something different. Before, you were saying that the advantage should grow as a function of interactions and quoted "the adversary's chance to defeat protocol goals will depend on how much she interacts with protocol participants--it won't significantly depend on her off-line computing time." But of course, it depends on both computation (time) and interactions and both are captured in the formal definitions given in the paper.

> 
>  As Remark 8 notes, "The resistance to dictionary attacks is captured
> by the first term which is the number of send queries divided by the size
> of the password space." Making q_se = N means that the number of
> interactions is equal to the size of the password space and that does
> not capture resistance to dictionary attack.

In your brute force attack, you're either making N connections to the server or you're watching a connection passively and computing N possible master secrets and seeing which enable to you decrypt. Either takes time at least N and both are captured in the notion of advantage. So if Adv(t,q) is the maximum advantage of an adversary running in time t, making q queries (similar to the definition of Adv_G^{dh} on page 149), we have either Adv(N,N) = 1 or Adv(N,0) = 1. Neither result is particularly meaningful and certainly doesn't tell us that TLS-PSK is insecure.

> It is obvious that a making n large enough can make a dictionary attack
> moot. I have not said otherwise. It just doesn't make _the protocol_
> resistant to dictionary attack.

This isn't a useful distinction then since no mode of TLS is resistant to dictionary attacks by what I take to be your definition.

-- 
Stephen Checkoway