One topic not directly connected to SASL2, but to channel-binding and SCRAM in general, is the security of TLS. When discussing about whether PLAIN is a good choice or whether channel- binding has any benefit or even if SCRAM is needed, the underlying problem ist, that everyone has another view upon how secure TLS is. And that view influences the discussion about these topics.
Let me sum up some of the properties SCRAM and channel-binding offer, before diving into the TLS stuff itself. Channel-binding: Channel-binding allows client and server to agree upon using the same TLS channel without a MITM between them. While the relatively weak "tls-server-end-point" channel-binding only makes sure the same certificate as used by the server is seen by the client, other channel-binding types like "tls-exporter" are really strong, coupling every newly established TLS channel to a unique random-looking value. SCRAM: Salted Challenge Response Authentication Mechanism allows mutual authentication for server and client (to be exact: SCRAM allows each party to proof that they know the password or a hash thereof). That allows for servers not storing the plaintext password, but a salted hash of it. It allows for clients doing the same, but that prevents them to use any other authentication method than exactly the SCRAM flavor the password was originally stored in. Most clients therefore use the (often hardware backed) keystore of their operating system to store the password securely. Yes Marvin, I consider the storage of password hashes on the user's devices of no practical relevance here. But the storage of those hashes on the server is. SCRAM uses nonces to make the SCRAM exchange replay-save. Even if an attacker records the whole SCRAM exchange he won't be able to use this data to authenticate himself (as long as the hashes SCRAM is based upon have not been broken). TLS: Yes, TLS 1.2 and 1.3 itself is secure (as of today), but the PKI is not. There are numerous shortcomings and I recommend reading Bruce Schneier's article over here: https://www.schneier.com/academic/archives/2000/01/ ten_risks_of_pki_wha.html Some of the issues mentioned therein are still valid today. - I have seen schools and companies demanding to install their CA into phones and computers to access the internet over wifi. These MITM boxes create new certificates on the fly while filtering internet access and frequently exhibit security holes. - Certificate Transparency doesn't work automatically: you'll have to monitor your domain yourself, to detect misissuance. That's something operators of small home-deployments most probably won't do. - Certificate Revocation Lists are frequently not checked at all (we don't even do OCSP stapling in our open source xmpp servers, mobile platforms even seem to not support OCSP stapling at all), stolen private keys can be used for the rest of the lifetime of a certificate (that could be up to a full year!) - People often click away certificate trust warnings - CAs still misissue certificates, despite certificate transparency - Bugs like Heartbleed allow stealing of private keys - Russia and other states are trying to lead people to install their CA: https://bugzilla.mozilla.org/show_bug.cgi?id=1758773 - many more Yes, the web platform solely relies upon TLS, but that does not mean that it's the holy grail of internet security. Even older TLS versions like TLS 1.0 or SSL 3 are deemed insecure today. If we can improve the security beyond simply using TLS, we should. More so if this does not have any negative side effects (like disabling PLAIN in every client would have on these deployments only supporting PLAIN). To me, supporting SCRAM (the whole family, not just SCRAM-SHA-1) and channel- binding is a valuable goal to strive for as a second layer of defence even when using TLS. Defense in depth is something that's important. It borrows people some time after one layer of defence is broken, but before all software (server and clients) could be upgraded. And yes, this defence in depth has to be established some time *before* another layer of our security gets broken, not afterwards. Journalists, activists and other people at risk of being MITMed benefit from this additional defense, too. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
