[tialaramex]

TLS is designed to let you replace the provided peer authentication, people have looked at drafts to hook a PAKE into TLS 1.3 in the past but those drafts have expired. There has more recently been interest in trying again. You can even (though it's discouraged) just make the right noises to get appropriate enumerated values reserved for your mechanism, and ship it, without the hassle (valuable as it would be for actual security) of peers offering their opinions and maybe not doing things how you prefer.

I don't see how certificates are relevant at all? You clearly don't want a certificate if you intend a PAKE to provide mutual assurance of identity.

I think Colin grossly overestimates the chances of some bozo getting an RSA (of all things) transport protocol to work securely. My guess is that most attempts will end without it working at all (frustrating but safe) but a potentially very scary number would work in the sense that they seem to function as intended while not delivering the expected security through a combination of ignorance and inadequate testing. I particularly don't buy that a bozo who actually does get all that right can't instead write code against OpenSSL without ripping a hole in the universe. I don't like OpenSSL, but even I can see that it gets enough hard things right to be a useful contribution.

[mmm_grayons]

There is already an older PAKE in TLS, TLS-SRP. It doesn't apear to be well-loved [0] and I don't know enough about the IP situation to use it confidently, so I've been looking through the CFRG reviews on PAKE candidates [1] to get more info.

I mentioned certs because they're a pain to manage and are generally how people do TLS, though there are a few PSK options [2].

Your right that implementing a secure RSA protocol by one's self is difficult. That's the idea of things like Noise, to make messing up your own protocol implementation harder (albeit not impossible). The other option is building on something like libsodium that has a good, well-documented API and is hard(er) to screw up.

TLS certainly works for a lot of things, it just doesn't work for everything. For that reason, something that bakes it in probably won't replace TCP.

[0]: https://blog.cryptographyengineering.com/should-you-use-srp/

[1]: https://github.com/cfrg/pake-selection

[2]: https://tools.ietf.org/html/rfc4279

[tialaramex]

You can't use the stuff you linked with TLS 1.3, and of course you can't use an older TLS version in QUIC. It's possible you knew those things, but I want to make sure.

My recent experience with the password manager that was linked on HN shows me that even an abuse-resistant API like Sodium cannot stop people being idiots. (The author believs some random passwords aren't "unique enough" so they have written a bunch of code on top of Sodium to avoid passwords like '4K2m_chmJ$gD' which they feel wouldn't be suitable because it has the letter 'm' more than once...)

[mmm_grayons]

I hadn't checked compatibility and wasn't aware they no longer included SRP. It's not the best PAKE, but to my knowledge, not cryptographically broken (Apple uses it for a bunch of stuff, IIRC). Thanks for letting me know.

And you're right, that's pretty dopey with the password manager. I understand the point of password security measures, but just do something like pam cracklib. There's no such thing as an idiot-proof library. Honestly, that looks like the developer was being kind of lazy, using a constant size for things like max password length.

My only point here is that there are libraries that are well-tested, secure, and at least as idiot-proof as openssl. The increased ability to do the protocol wrong with something like libsodium is balanced by the increased ability to do the crypto wrong with something like openssl.

[tialaramex]

They didn't explicitly deprecate TLS-SRP, it simply can't work in TLS 1.3 because although it superficially looks like a minor revision, and indeed (to defeat middlebox ossification) on the wire it appears to say it is only TLS 1.2 in reality it's a fairly radical change.

TLS-SRP bolts over the traditional TLS key exchange mechanism, which made sense, but in TLS 1.3 that entire mechanism is gone, keys are either pre-shared or they're always agreed in the first protocol burst using an (elliptic curve) Diffie Hellman method. So by the time you'd have a natural opportunity to do SRP the protocol has already agreed keys anyway.