You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How do we want our users to use TLS? imap-flow can be used with anything that is AsyncRead + AsyncWrite. Thus, we don't dictate any technology for now. Still, I think we need to think -- at some layer -- how to make usage of TLS easy and usage of plaintext "ugly" (by putting insecure, danger, ... somewhere). When we do so, we can provide good TLS defaults, i.e., use ALPN, SNI, etc.
Question: What layer should it be? One could say that TLS needs to be done in imap-flow due to STARTTLS. But I would argue that we 1) should try to avoid implementing STARTTLS as long as possible (asking stupid questions like "Do you really need it?"), and 2) implement it as an isolated connection "prefix".
I.e., ...
let stream = Tcp::connect();// No real IMAP implementation! Only ...// 1) consume a line (greeting bytes, don't care)// 2) send "A STARTTLS"// 3) consume a line (response bytes, don't care)// 4) TLS handshakelet stream = ImapStartTls::connect(stream);
Idea is: We do expect a very simple STARTTLS handshake. If anything unexpected happens, step 4 will fail anyway. It could be required to do a bit of response checking, i.e., consume lines until "A OK " was found. But we don't want to do any IMAP processing here as everything we may learn MUST be discarded anyway.
How do we want our users to use TLS?
imap-flow
can be used with anything that isAsyncRead + AsyncWrite
. Thus, we don't dictate any technology for now. Still, I think we need to think -- at some layer -- how to make usage of TLS easy and usage of plaintext "ugly" (by puttinginsecure
,danger
, ... somewhere). When we do so, we can provide good TLS defaults, i.e., use ALPN, SNI, etc.Question: What layer should it be? One could say that TLS needs to be done in
imap-flow
due to STARTTLS. But I would argue that we 1) should try to avoid implementing STARTTLS as long as possible (asking stupid questions like "Do you really need it?"), and 2) implement it as an isolated connection "prefix".I.e., ...
Idea is: We do expect a very simple STARTTLS handshake. If anything unexpected happens, step 4 will fail anyway. It could be required to do a bit of response checking, i.e., consume lines until "A OK " was found. But we don't want to do any IMAP processing here as everything we may learn MUST be discarded anyway.
Related
The text was updated successfully, but these errors were encountered: