Re: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP

[Stephen Farrell <[e-mail]>]

Hiya,

I didn't read the drafts, but Nick's comments make sense to
me so I'd give those a +1 (modulo not having read the draft
of course:-)

One other thought...

On 19/08/2019 17:07, Kai Engert wrote:
> If the client
>   supports it, and if the connection is encrypted, then the client
>   sends its client side identifier.

Sometimes I've been prompted to accept a hotspot's bogus
certificate for IMAP if my MUA is the first to trip over
a hotspot. A user might hit yes in such a case which is
a bad idea yes, but I guess happens. I guess an active
attack could appear similarly.

So is there a reason to tie the CLIENTID to the server
credentials I wonder? E.g. to rotate it whenever the
server cert changes. That might also discourage servers
from assuming that the CLIENTID never changes.

However, were I asked what I'd like to see in TB and
IMAP servers, it'd be some usable (i.e. invisible:-)
way to do an SSH-like IMAP authentication, so the
server doesn't need to have a listener that accepts
password based auth at all. (I have a number of VMs
where the IMAP/SUBMIT ports are the only ways into
anything that still accept passwords.)

So, instead of a CLIENTID, I'd love to see TB generate
a key pair when you add the account and for the user to
only have to use the IMAP password at that stage and
not every time the MUA connects to the IMAP or submit
server. And rotate that key pair every N connections.

Any chance of that instead? (He asked cheekily:-)

Cheers,
S.