Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, May 17, 2018 at 1:33 PM, Benjamin Kaduk <[e-mail]> wrote:

> On Thu, May 17, 2018 at 01:22:04PM -0700, Eric Rescorla wrote:
> > On Thu, May 17, 2018 at 1:04 PM, Brandon Williams <
> > [e-mail]> wrote:
> >
> > >
> > > That having been said, I'm having trouble reconciling Ekr's "I don't
> see
> > > how a weakness in MD5 is relevant here" with Matt Miller's earlier
> comment
> > > "I am wondering why a more robust password algorithm (key derivation
> > > function) was not defined (e.g., HKDF-SHA-256)". Matt appears to
> suggest
> > > that we should go farther than we have while Ekr appears to suggest
> that we
> > > might not need to have gone even that far.
> > >
> > > Any suggestions about path to resolution on this? Am I just completely
> > > misinterpreting the comments we've received so far?
> > >
> >
> > Well, I don't know what Matt is thinking. Perhaps he would like to weigh
> in?
>
> I think this is a question of "attack over the network" vs.
> "compromised password database".  You want HKDF-SHA-256 or Argon2 or
> something like that because it makes it harder for an attacker to
> brute-force a compromised database of hashed passwords, which is
> something of a different concern than turning a string into a crypto
> key and worrying about an attacker in the network that only observes
> the ciphertext.  That is, the problem of brute-forcing the secret material
> given the network ciphertext is different from attacking the
> (hashed) password database directly.
>

Right. But the weak password hashing function is a problem if you have
the data on disk, whether you negotiate it or not, so biddown protection
doesn't help.

-Ekr

So it seems possible that both points are relevant, just protecting
> against different things.
>
> -Benjamin
>