ircv3-specifications
ircv3-specifications copied to clipboard
ircv3
Add sasl-ir extension
Implemented in Matrix2051: https://github.com/progval/matrix2051/commit/e03f2be5f1dba14951158a0738dbee54f651f21b
Independently of this spec, thoughts on adding a non-normative caution to the SASL spec, recommending that unrecognized mechanisms should not be logged?
could there be some guidance regarding mechanisms that are server-first? e.g. should the server explicitly abort if IR is used but the server's initial challenge is not empty (i.e. if it's not "AUTHENTICATE +")
I don't remember such mechanisms offhand (and the existing ones wouldn't be relevant for IRC to be fair) but afaik they do exist
Summarizing some discussion from #ircv3, it seems like in order for this extension to provide a speedup, the client has to cheat slightly (by caching a previous CAP LS 302 response from the server, so that it knows that sasl-ir is available even without a CAP LS roundtrip). But if the client is willing to cheat a little more than that (by caching the availability of sasl=PLAIN), then it can get the speedup even without this extension, by preemptively sending its SASL messages without waiting for acknowledgement. (To be clear: I think this kind of cheating is good and should be encouraged in mobile clients.)
The goal of this extension is not to provide a speedup (clients can already do it), it's to make the protocol more reliable. If the client caches sasl=WHATEVER and the server happens to change their supported capabilities, then the credentials are interpreted as a SASL mechanism by the server.
If the client caches sasl=WHATEVER and the server happens to change their supported capabilities, then the credentials are interpreted as a SASL mechanism by the server.
Are we talking about a TOCTOU race between the server sending a CAP LS 302 response including sasl=PLAIN and the client attempting to use it, within the same session?
Or is the idea that a cached cross-session observation of sasl-ir is more stable than a cached observation of sasl=PLAIN? (In theory, a cached observation of sasl-ir can also become invalid.)
The idea of this extension is to make it safer to pipeline AUTHENTICATE commands without waiting for the CAP LS reply, by making it explicit which parameters are credentials and sensitive info in an AUTHENTICATE command. Right now a server can't make the difference between the start of a SASL exchange and the first initial response sent by the client.
Maybe stop using the same keyword AUTHENTICATE to pass both mechanism and response, and start using different keywords for them?
If we want to make bigger changes, I'd suggest adding a * parameter indicating a continuation like CAP does:
AUTHENTICATE PLAIN
AUTHENTICATE * <base64>
The idea of this extension is to make it safer to pipeline AUTHENTICATE commands without waiting for the CAP LS reply, by making it explicit which parameters are credentials and sensitive info in an AUTHENTICATE command. Right now a server can't make the difference between the start of a SASL exchange and the first initial response sent by the client.
This issue would still exist for line continuations, right?
It seems to me that the concerns here don't really justify adding complexity to one of the most widely implemented and deployed IRCv3 specs.
(For what it's worth, the draft as written still has a performance rationale in the introduction section. I think I understand most of the robustness rationale now, but I'm still not really convinced.)