Move display names to protected headers in verified chats

[link2xt]

If chat is verified (group chat or verified 1:1 chat) we should put From: and To: fields with only addresses and no display names into the unencrypted part. Encrypted part should contain the same fields, but with display names.

Empty display name passed to Contact::add_or_lookup is already treated as "prevent rename" and receive_imf::from_field_to_contact_id relies on this, so even if old client does not get to protected header it will not result into renaming everyone into "".

We can also extend this, but for the first implementation this is out of scope unless it makes implementation easier:

1. Move display names to protected headers for all Autocrypt-encrypted messages. This would be even better but need to check in advance that at least Thunderbird handles it.
2. Completely remove the To: field in "undisclosed recipients" for verified chats. Need to check that this interacts well with decryption failures and does not result in removing everyone from the group.

[link2xt]

Current testing results is that Thunderbird stores From and To in protected headers but does not extract them, at least th display name from From.

K-9 aka Thunderbird for Android only extracts Subject and only stores Subject.

[Septias]

As link2xt mentioned in the comment above, Thunderbird and K9 don't show display-names when we only put them into the encrypted part. The related PR (#5183) removes all display names from unencrypted emails and moves them into the encrypted part so email client users will no longer see display names. As link2xt pointed out here (https://github.com/deltachat/deltachat-core-rust/pull/5183#issuecomment-1898704689) we are not sure if that is what we want. We could add a check so that the display names are only moved into the encrypted part for verified chats. What do you think @r10s @hpk42

[hpk42]

On Tue, Jan 23, 2024 at 00:33 -0800, Sebastian Klähn wrote:

As link2xt mentioned in the comment above, Thunderbird and K9 don't show display-names when we only put them into the encrypted part. The related PR (#5183) removes all display names from unencrypted emails and moves them into the encrypted part so email client users will no longer see display names. As link2xt pointed out here (https://github.com/deltachat/deltachat-core-rust/pull/5183#issuecomment-1898704689) we are not sure if that is what we want. We could add a check so that the display names are only moved into the encrypted part for verified chats. What do you think @r10s @hpk42

I saw that Thunderbird just added Autocrypt-gossip support:

https://www.thunderbird.net/en-US/thunderbird/115.7.0/releasenotes/?uri=/thunderbird/releasenotes/

so i guess they would be open to pull displaynames from the protected headers.

For right now, only protecting displaynames for guaranteed encryption sounds fine because guaranteed encryption is what we are recommending for maximum security/privacy, anyway, and kind of the default mode for chatmail usage. And the check is cheap. When and if Thunderbird/K9 also protect Displayname-metadata in the future, we could remove the check and always perform this metadata-reduction. Last time i checked, btw, Thunderbird was not very smart about learning e-mail addresses and display names from To/CC fields but i am not super-actively using it.

[iequidoo]

So, for the From name it is implemented, as suggested, only for verified chats, but To display names are protected for all encrypted emails as compatibility seems less critical here.

TODO: create an issue in the TB bugtracker at least. It should actually use and prefer From/To/etc. display names from the encrypted part. DONE: https://bugzilla.mozilla.org/show_bug.cgi?id=1901636

[iequidoo]

I think this is underimplemented now. Names are not revealed in verified chats, but during verification (i.e. SecureJoin) they are still sent unencrypted. Going to fix this

[link2xt]

We can implement "Legacy Display Element" from the new standard https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/, then there is no need to wait for Thunderbird and K-9 (aka Thunderbird for Android) to support it. Original To and From will go into the encrypted part and legacy display, while on the outside we can use From with hidden display name and To: Undisclosed recipients:; instead of the original To field. No need to distinguish between verified/non-verified chats then.

The new standard is not finished yet, so I am not sure we need to jump to implementing it as a whole. In particular, "wrapped" hp-scheme can be completely ignored even for reception as it is not widely implemented and is likely to be removed from the RFC. HP-Outer headers we can generate but because they are only used in the reply procedure to generate temporary HCP and the procedure is not easy to implement in Delta Chat because we don't store original message headers. I suggest we completely ignore HP-Outer on the receiving side and instead use the strictest HCP we can, exposing only From address, Message-ID, In-Reply-To, References and Chat-Version. We can think about hiding In-Reply-To and References later but for now I would not do it because it will affect chat assignment for non-fully-downloaded messages again.

https://bugzilla.mozilla.org/show_bug.cgi?id=1901636

Thunderbird/K-9 is likely to implement https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ once it is ready anyway. You can point to this draft in the issue, but Thunderbird developers are already aware of this RFC draft.

[link2xt]

I think we better wait until https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ is more stable, it uses new Content-Type parameter hp instead of protected-headers="v1" of https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ We can add some support for reception of such messages already, i.e. recognize hp-legacy-display=1 parameter on text/plain and strip legacy display part, but better generate protected-headers="v1" for now until Thunderbird gets at least some support for the new hp parameter.

We cannot start using new hp header protection yet because then Thunderbird will not even recognize protected Subject as it currently does not support the new standard.

[iequidoo]

We can implement "Legacy Display Element" from the new standard https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/, then there is no need to wait for Thunderbird and K-9 (aka Thunderbird for Android) to support it.

Yes, but we should first implement removing these "legacy display elements" and only after maybe several months we can start adding them, otherwise not yet updated users will see them in messages of non-verified chats. OTOH that will be a good reason for them to update :)

We cannot start using new hp header protection yet because then Thunderbird will not even recognize protected Subject as it currently does not support the new standard.

This means we still should add protected-headers="v1" parameter, i.e. use both for a while. Anyway, adding a support for the proper displaying of messages using the hp-legacy-display=1 scheme should be done first, then we can start to generate such messages and not reveal any names in encrypted communication.