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 <stephen.farrell@xxxxxxxxx> 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.