On 12/08/2014 04:10 PM, Thijs Alkemade wrote: > Are you suggesting a scenario where the attacker can *insert* data that causes > DIGEST-MD5 to be used, but can not just *remove* the SCRAM-SHA-1 offer, only > leaving DIGEST-MD5? That sounds rather far-fetched to me. In practice, either > an attacker can make arbitrary modifications, or none at all (due to TLS).
Doesn't matter; let's assume they can arbitrarily modify things. If they can, this means that they can force the user to fallback to a less secure auth mechanism as the RFC is currently worded. However, if fallback weren't an issue, all they could do (to a client who supports a more secure mechanism) is cause a DoS. > Pinning the mechanism used sounds like a good idea to me, though I would say > clients should refuse to use anything weaker. Yah, agreed; this is what we do in Conversations (client for Android). So I'm not missing something; this sounds like a potential security concern in the RFC to me. Maybe something that should be considered for change? Or maybe an best practices XEP that outlines when fallback should happen and when it shouldn't to mitigate these kinds of downgrade attacks would be more appropriate (and easier as it's not a full RFC)? Thanks, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
signature.asc
Description: OpenPGP digital signature
