Name (and describe) the Header Confidentiality Policy used by Delta Chat [RFC 9788]

, , ,
1

RFC 9788 “Header Protection for Cryptographically Protected Email” includes the following statement:

The authors of this document hope that implementers with deployment experience will document their chosen HCP and the rationale behind their choice.

The Header Confidentiality Policy used by Delta Chat is easy enough to describe. In RFC 9788-style pseudocode, it might look like this:

hcp_unnamed(name, val_in) -> val_out:
    if lower(name) is 'from':
        assert that val_in is an RFC 5322 mailbox
        return the RFC 5322 addr-spec part of val_in
    else if lower(name) is 'to':
        return '"hidden-recipients": ;'
    else if lower(name) is 'date':
        return a random date within the last 7 days
    else if lower(name) is 'subject':
        return '[...]'
    else if lower(name) is in ['message-id', 'in-reply-to', 'references',
                               'chat-version', 'chat-is-post-message']:
        return val_in
    else:
        return null

I would like to adapt this Header Confidentiality Policy for bower (GitHub - wangp/bower: A curses terminal client for the Notmuch email system · GitHub) as a configurable option for advanced users – so it would be handy if I had a name for it (and maybe a URL I could point to). I also expect that Delta Chat will modify the Header Confidentiality Policy in the future. E.g. to also mask (or spoof) ‘message-id’, ‘in-reply-to’, and ‘references’. So maybe a name like ‘hcp_delta_chat_2026’ or ‘hcp_delta_chat_0x01’ would work well?

For my own needs, it would be enough if there was a simple txt/html/md file on the website or on Github that names and describes the Header Confidentiality Policy (or, in the future, Policies) used by (different versions of) Delta Chat. But if you are very ambitious, RFC 9788 also includes guidance on how to register a Header Confidentiality Policy with IANA.

2 Likes
Nondetectable version [protocol cloaking against censors, hide Chat-Version]
2

in-reply-to and references is already protected in the latest version, so it should be return null too.

chat-version we want to protect and don’t rely on it being unprotected, but currently send it in the outer header. This is just for compatibility, because of server filtering and “move to deltachat folder”. You can hide it already, sending unprotected Chat-Version maybe even does more harm because at least in the past mailcow shipped with a preconfigured filter that marked chat messages as seen immediately and users got no notifications.

So only Message-ID and Chat-Is-Post-Message is copied. Message-ID should not be hidden because it is a random UUID for deduplication and leaks no data. Chat-Is-Post-Message would be nice to get rid of, the reason we went for it instead of just the size limit is that it is difficult to control the resulting message size after compression, encryption, and headers the servers add.

3

I created docs: document Header Confidentiality Policy by link2xt · Pull Request #8016 · chatmail/core · GitHub, let’s continue there.

1 Like