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.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
