Re: New work for sacred working group?

Can you give a URL for "that I-D"? From Stephen's description, it sounds 
like an active attacker
would have an opportunity for a dictionary attack. Also, using TLS might 
be more
heavyweight than necessary. A pure credentials download protocol with no 
dictionary attack
can be done with two messages, and small enough messages that it could 
be done on top of UDP
without fragmentation.

Radia



Stephen Farrell wrote:

>
>
> Hi Peter,
>
> So you're saying that TLS_DHE_PSK_WITH_AES_128_CBC_SHA is
> a ciphersuite that can meet the requirements for use in
> a sacred protocol, and does better than what we've got now.
> (I also presume that you're not arguing that we should
> do work here just because that's true, but do correct me
> if I'm wrong there:-)
>
> As I read it, that works by basically appending a (hashed?)
> password to a D-H derived key (with some length fields)
> and using the resulting value as the TLS pre-master key.
> Presumably the handshake falls over at the finished message
> if the wrong password was used.
>
> I'll have to read that I-D again and think about whether it
> really is better than the current sacred scheme, (and whether
> in that case, it means new work here would be more or less
> interesting...)
>
> Has anyone else an opinion on this as a basis for credential
> download? (And how it'd compare with SPEKE and/or the
> newly-proposed/10-year-old Radia/Charlie variation?)
>
> Stephen.
>
> Peter Gutmann wrote:
>
>> Stephen Farrell <[email protected]> writes:
>>
>>
>>> So I would guess that for sacred, TLS-PSK isn't an unencumbered 
>>> equivalent
>>> since offline dictionary attacks are a high priority here. Or am I 
>>> misreading
>>> something?
>>
>>
>>
>> Oh, that's only if you use the weakest (most lightweight) form of 
>> PSK, with
>> the entire shared secret being the PSK.  In this form it's assumed 
>> that you'd
>> be using a high-entropy key rather than just a password.  The 
>> stronger (but
>> more heavyweight) forms use a standard RSA or DH exchange (alongside 
>> the PSK
>> data), so this isn't an issue.  Note that even the most heavyweight 
>> form, DHE
>> + PSK, only has the same overhead as the SPEKE/SRP/etc-type protcols.
>>
>> Peter.
>>
>>
>