On Thu, Jan 24, 2019, at 14:40, Evgeny wrote: > Can someone please clarify how to maintain ineroperablity of SCRAM- > SHA1 vs SCRAM-SHA256 vs SCRAM-SHA-WHATEVER, e.g. when some clients > support SCRAM-SHA1 only, but the password was created in SCRAM-SHA256 > format. I know it's still possible to authenticate via PLAIN, however:
To my knowledge, we don't have a good solution for this. This is the problem with proof-of-posession based mechanisms like SCRAM: if you never know the password after the first time it's set, it's hard to be agile with your mechanisms without requiring a password reset. Arguably, this makes them not a good idea because being able to rotate the password storage mechanism quickly in case a vulnerability is discovered in the current mechanism is a nice property to have, whereas the server not knowing the password is less valueable unless you are forced to use a server that you're worried might become malicious in the future (which is probably unlikely). > Another problem is with "-PLUS" formats. RFC 7677 states: > > > After publication of [RFC5802], it was discovered that Transport > > Layer Security (TLS) [RFC5246] does not have the expected > > properties for the "tls-unique" channel binding to be secure > > [RFC7627] > > Does that mean that "-PLUS" doesn't provide additional security and is > now useless? This is true during resumption, so you can use -PLUS as long as you're not resuming an existing TLS session. For more info see: https://mitls.org/pages/attacks/3SHAKE#channelbindings Once the extended master secret fix has been widely adopted (I'm not sure what the current status of this is) this will stop being a problem. Depending on the TLS library you use, it may also not give you the TLS first message unless you're not doing renegotiation, in which case you're also safe. > I'd like to see XSF taking a clear position on this as well as > creating some recommendation for the implementors because the > disambiguation creates interoperability problems. This is a good idea. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
