Re: [TLS] PSK in 1.3?

[Watson Ladd <[e-mail]>]

On Mon, Feb 23, 2015 at 7:08 PM, Stephen Checkoway <[e-mail]> wrote:
>
> 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.

As far as I can tell, neither of you actually are arguing about what
you're actually arguing about. The question isn't whether PSK mode
satisfies the Bellare-Pointcheval-Rogaway definitions. Instead, it's
about using in TLS 1.3 vs replacing it with a mode that uses a PAKE
instead. The stated argument is that PSK is getting deployed with
passwords instead of keys in many places: that's completely orthogonal
to the discussion that's been taking place.

As far as how much PAKEs cost, SPAKE2 is 2.5 exponentiations per side.
Elligator is 2, but slightly harder to implement. On 32-bit arm
processors I think these exponentiations cost around 2 million cycles
according to SUPERCOP.  So not a completely trivial cost, but most
processors will do better, and I think the measurement was borked due
to compiler issues.

(Elligator might even be possible on genus 2: let me think about that
for a while. Certainly on hyper-and-elliptic. )

Sincerely,
Watson Ladd

>
>>
>>> 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
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin