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

[Brandon Williams <[e-mail]>]

OK, so based on this, it seems that the WG was right about the desire to 
move away from MD5 but unclear about the reason. If the goal is to 
mitigate against keeping weak hashes in a local database on the server, 
the doc should be clear that this is risk and explain how bid-down helps 
achieve the goal.

Depending upon the internal implementation on the server, bid-down 
protection could be important as part of a model to help the server 
avoid caching weak precomputed password hashes to insecure local storage 
I suppose. For example, if the server computes the hash using the 
negotiated algorithm and then writes the hash to a local cache to avoid 
having to calculate it again, it would be good to avoid generating weak 
hashes that could be leaked from a compromised server. Of course, this 
is only really meaningful if the server has strong protections around 
the the username/password database that's required to generate the hash 
values in the first place.

Does this seem like it would be going in the right direction?

--Brandon

On 05/17/2018 06:17 PM, Matthew A. Miller wrote:
> On 18/05/17 14:33, Benjamin Kaduk 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.
>>
>> So it seems possible that both points are relevant, just protecting
>> against different things.
>>
> 
> My initial thoughts were along the lines of "compromised database",
> which admittedly data-at-rest is at the top of my mind most of the time.
>   The key derivations in this document are ok for how they are used.
> 
> I thought I'd backed away from that robustness point in the email
> discussion that ensued from the review, as it sounded like a concern
> that was out of scope for this work.  If offline attacks are in-scope
> then something that makes brute force take some real work (at _a
> minimum_ PBKDF2 with 10k+ iterations, or better yet use scrypt or
> argon2).  If it's out-of-scope, then this needs to be called out in the
> security considerations.
> 
> Otherwise, I think a valid concern to implementers is that MD5 is
> getting removed from or turned-off in various base libraries and module.
>   Moving away from it helps implementations avoid having to rely on older
> (and potentially vulnerable/exploitable) base libraries just to keep an
> algorithm around seems very worthwhile.
> 
> 
> 
> - m&m
> 
> Matthew A. Miller
>