On 12 Dec 2014 19:10, "Sam Whited" <[email protected]> wrote: > > > > 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. >
I don't think that assertion is true. If a third party can arbitrarily change data on the wire, they can do pretty much anything, including session hijack. > > 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)? > What do you think is not covered in the security considerations section of RFC 4422, in particular section 6.1.2? > Thanks, > Sam > > -- > Sam Whited > pub 4096R/54083AE104EA7AD3 > https://blog.samwhited.com >
