1549590 - consider executing IMAP ID to just before authentication

Status: NEW

(MailNews Core :: Networking: IMAP, enhancement)

Description

[Wolfgang Rosenauer [:wolfiR]]

Currently Thunderbird (and SeaMonkey fwiw) execute the IMAP ID command right after authentication.
https://dxr.mozilla.org/comm-central/source/comm/mailnews/imap/src/nsImapProtocol.cpp#8203

This ID command submits the client id to the server and gets also a response back from the server.
This is described in RFC 2971.

The RFC does not specify when that ID command should or can be used but I would like to ask to get this moved in the process to before the actual authentication instead after for the following reason:

During the login process there might be some kind of policy checks going on and client id information could be interesting to detect anomalies of user behaviour in case of attacks to the mailbox.

The RFC clearly states that access must not be blocked based on client information which is not the intention here.

But imagine the following scenario:
I as a user always log in to my mailbox using the same clients. e.g. Thunderbird and K9-mail and probably one webmailer). Now there is a new login coming from an unexpected device. When this information is available, an attack detection system could recognize this anomaly and at least notify the user that his account was accessed using a "new device" for him to check.

I know that the use of the ID command is completely voluntary and also there are other clients which also do it at some point after login.
Still changing it has some benefits and I do not see significant drawbacks from that. Therefore please consider.

I might be able to look into the actual patch if it will be considered. But first I'd like to have some comments if it would be.

Comment 1

[Wayne Mery (:wsmwk)]

Thoughts?

Comment 2

[Kai Engert (:KaiE:)]

A general question first:
What kind of information is currently sent by Thunderbird? Could you please provide an example?
RFC 2971 warns about potential privacy issues with it.

Regarding the suggestion to execute the ID command at a different time of the IMAP connection, I don't have an opinion yet.

Comment 3

[Wolfgang Rosenauer [:wolfiR]]

According to my Dovecot logs Thunderbird is sending:
ID sent: name=Thunderbird, version=68.2.0

Just a counter example from an Android mail client:
ID sent: name=com.samsung.android.email.provider, os=android, os-version=8.0.0; R16NW, vendor=samsung, x-android-device-model=SM-G930F, x-android-mobile-net-operator=Telekom.de, AGUID=<DELETED>: user=<>, rip=<DELETED>, lip=<DELETED>, TLS, session=<CBh2ByqWs9kgAwDsU8mb/kH777mubiO+>

So for TB I do not have any privacy concerns with the current information sent.

Comment 4

[gene smith]

Sounds like it is a very similar concern as the "client id" feature that is currently in development: Bug 1532388 (and related bugs for detailed discussions).
Would the "attack detection system" for ID have to be added as a new imap server feature? (Client id also requires the sever to support the special feature.)
Not sure I understand why ID before or after login is important if an unexpected, new or no ID still allows login.

Comment 5

[Wolfgang Rosenauer [:wolfiR]]

(In reply to gene smith from comment #4)

Sounds like it is a very similar concern as the "client id" feature that is currently in development: Bug 1532388 (and related bugs for detailed discussions).

I didn't know about this draft RFC for CLIENTID. Also it seems to be stricter defined but does a very similar thing which could also already be achieved with ID?

Would the "attack detection system" for ID have to be added as a new imap server feature? (Client id also requires the sever to support the special feature.)

The actual real life usecase is that I'm running weakforced (https://github.com/PowerDNS/weakforced) in combination with Dovecot's auth policy integration (https://wiki.dovecot.org/Authentication/Policy).
So the IMAP server feature is just the availability of the ID command. CLIENTID is something which could extend that system but the information given currently via ID from TB would already be quite useful if it would be available at authentication time.

Not sure I understand why ID before or after login is important if an unexpected, new or no ID still allows login.

As described above the integration with the anti abuse system in that case happens during login and if ID is only provided afterwards it cannot be considered anymore even not for triggering a notification or for tarpitting.

Comment 6

[gene smith]

Ok, thanks for info.
But if the attacker sent the expected tb ID response "ID sent: name=Thunderbird, version=68.2.0", they would still gain unimpeded access. With clientid the attacker would have to guess and send the correct UUID (I think).
But I guess this would provide pretty good protections since it is probably unlikely that the attacker would choose the the correct ID response on the first try.

Comment 7

[Wolfgang Rosenauer [:wolfiR]]

(In reply to gene smith from comment #6)

But if the attacker sent the expected tb ID response "ID sent: name=Thunderbird, version=68.2.0", they would still gain access. With clientid the attacker would have to guess the correct UUID (I think).

The difference to CLIENTID is that this is just a weak indicator. Exactly the same way as websites use UA strings to notify users who accessed a certain account the first time with a new UA. Could be extended with something similar to a 2FA if an anomaly is found and yes, there is no cryptographic security in that.
CLIENTID is really more or less meant for stricter authorization.
At least ID is already a real RFC standard and implemented in many clients.

Now I read through almost everything about CLIENTID and I'm not convinced.
It's basically really more detailed specified ID command which ensures confidentiality by enforcing TLS and a certain format. ID could be implemented exactly the same way.
But not my call to really comment much on CLIENTID. Time will tell if anyone besides that company is doing anything with it especially if the server side concept to actually use the CLIENTID for abuse detection and authorization falls under a patent. At least so far I haven't heard of other servers to be interested in implementing it.
But compared to CLIENTID this one should be rather straightforward because there is no change in information being transferred just the timing when it is would be changed.