On Fri, Apr 26, 2024 at 06:45:57PM +0200, ilf wrote: > The Autocrypt project worked on a draft for "Protected Headers for > Cryptographic E-mail" [1]. That became the IETF draft "Header Protection for > Cryptographically Protected E-mail" [2]. draft-ietf-lamps-header-protection > is an Active Internet-Draft of the LAMPS WG, a "Proposed Standard" and it is > on track to become an RFC. > > 1. https://github.com/autocrypt/protected-headers > 2. https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/
Neat. But this feature seems like a misfeature, making you immediately susceptible to MITM. It encourages users to forgo establishing the trust of the keys so received. What's to stop me from sending you a forged e-mail that appears to be from someone else, with an address and public key that I control? Or, if I control their/your local mail server, just replacing the key they gave with my own? Part of the point of using PGP/GPG is that you have taken the time to verify the identity and key signature of the person presenting the key, to prevent MITM attacks and similar. This seems tailor-made to encourage less savvy users (or really everyone) to do exactly the wrong thing. If it's not worth your time and effort to verify your recipients' identity and keys, then encrypting your message probably isn't as warranted as you think it is--relying on your recipients' trust in their provider and ensuring both ends use SMTPS is almost certainly enough (if they don't, get some that do, and if you can't trust them, Autocrypt makes you susceptible to MITM). And if you do take the time to verify keys, then autocrypt is entirely superfluous. If neither is true, then maybe you need to re-evaluate how you are communicating, or perhaps whether you should be communicating at all. > Derek Martin: > > Yeah unfortunately, as Kevin admitted, this feature was never discussed > > here when it was implemented > > Within the Mutt project, both Autocrypt and protected headers were > discussed. I filed an issue in 2018 [3]. It was mentioned on IRC [4]. It was > mentioned on mutt-users [5]. 13 people participated in the discussion on > GitLab, among them an author of the current IETF draft RFC. That's all great except I don't follow any of those mediums, and none of those mediums are the established one for discussing the development of new/proposed functionality in Mutt. This list is. AFAIK the IRC channel was meant to be supplementary, not supplantory. Finally, to succinctly summarize my "C's" on the RFC, so that you need not read through the whole thread: 1. Subject protection is superfluous; instead use a placeholder subject and put the "real" subject in the body of the message. Every mail client that supports encryption already supports this, no new functionality required. This achieves both secrecy and tamper-proofing. 2. As far as tamper-proofing the headers, I personally would prefer putting the signature of the headers in a separate header (which obviously can't be included in the signature), because it doesn't require bloating the contents of the e-mail by doubling the space required to convey them (on top of any signature), and has no real ramifications for clients that don't support the feature (other than obviously they don't benefit from the signature). However, a separate encrypted MIME part will also work. 3. If you want to actually hide the headers, or a subset of them, a separate encrypted MIME part is the cleanest way to go. This again achieves both secrecy and tamper-proofing. These all satisfy the requirements but avoid the cases of duplicate headers or other parser bugs potentially causing headaches for less well-implemented clients. Aside from the need to document them, so that clients can implement the feature compatibly, they don't even really require new standards... They don't introduce new behaviors that are uncommon in existing clients. It is extremely unlikely that any mail client which supports arbitrary message headers and MIME parts (i.e. pretty much all of them) won't either be able to support these implementations, or happily ignore them. The existing design DOES introduce duplicated/shadowed headers in places where they aren't commonly, so bugs are--not guaranteed--just more likely. It's really that simple. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
