Re: New work for sacred working group?

Hi Radia,

Sorry, I should have included the URL [1] before.

Stephen.

[1] http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-09.txt


Radia Perlman wrote:

> 
> 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.
>>>
>>>
>>
> 
>