Hi Will,

On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> I hadn't known about the protected header feature for S/MIME / OpenPGP
> before this thread came up (though as mentioned elsewhere in the thread,
> it seems like mainline mutt already supports it going back 4-5 years...
> just defaulting to off and limited to the Subject header).

And you're not the only one.  I know at least one programmer, who works
in security, and didn't know about $crypt_protected_headers_write until
he received a message from me that used it, a few years ago.

> Seems like it's based on this draft:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/
> 
> That said, IMO, adding (and especially enabling by default) support for
> draft RFCs that aren't yet standard / ratified has caused problems for
> mutt in the past (for example, the 'Mail-Followup-To' draft, which mutt,
> basically alone among MUAs, still supports, but which expired, and
> hasn't been updated since 1997)....

As you said, mutt(1) already has partial support for it, from several
years ago.  (It supports the sending side; not the receiving one).

Some of my patch sets to neomutt(1) do:

-  Add support on the sending side (neomutt(1) didn't have this).
-  Add support on the receiving side.
-  Enable it by default.

If you prefer to wait for it to be standard, I'm fine with it.  The
draft says it expires in 2024-09, so I'll check around that date to see
if they have done a release, and come back with patches for mutt(1).

> There's probably a balance of some kind to be struck between being
> appropriately concerned about security / not completely dismissing
> potential concerns, or being too slow to embrace new standards, but also
> not jumping too enthusiastically into solving theoretical problems that
> have complicated solutions.

While implementing all of it could be complex, my idea would be to only
implement the most basic part of it:

-  Print the protected headers, just like mutt(1) already does with the
   protected "Subject".
-  Enable it by default.

I've written code for these, and they seem quite simple.

Then some other feature could be to compare the headers against the
exposed ones, and emit a warning line if there are headers that don't
match.  This could lead to false positives with mailing lists that are
destructive to the original message, so this needs more careful
discussion.  But just showing the headers would already be enough to be
able to detect attacks by visual inspection, so I would be happy enough
with that.

> While the examples outlined as possible
> problems seem maybe technically possible, to me, as described, they
> don't seem to equate to a very serious security problem,

Yeah, it's not like a backdoor in xz.  We're not in a hurry to fix it.
But that's not to say that it's not a security vulnerability.  It's just
not a RCE.

> and in most
> cases, probably can be handled via common sense.

I'm not sure that's true.

> 
> Compared to the example of Thunderbird mentioned, I would say that mutt
> has a relatively more technical user-base, and one that may prioritize
> truth over beauty, esp. when it comes to email headers; sticking headers
> into the message body, but hiding them and / or rendering them in a
> different place seems kind of counter to Mutt's overall ethos.

Well, then I understand you agree with my intention to unhide those
header fields that mutt(1) currently writes but doesn't render?

> It's odd to me that, since OpenPGP and S/MIME both support MIME
> encapsulation that the draft standard wouldn't use a separate MIME part
> to handle the protected headers vs. stuffing it at the top of the
> message body, which just seems kind of kludgy at best.

The protected headers are part of the header area of the MIME part.
They are not part of the body area.  Below is a message, which you can
find on mutt-dev@'s archives at
<https://marc.info/?l=mutt-dev&m=171352201829360&q=mbox>.  You'll see
that the protected header fields are in the header area of the first
MIME part.

        From mutt-dev  Fri Apr 19 10:22:49 2024
        From: Alejandro Colomar <alx () kernel ! org>
        Date: Fri, 19 Apr 2024 10:22:49 +0000
        To: mutt-dev
        Subject: Re: Message security; protected header fields
        Message-Id: <ZiJF_4yY0sxn762s () debian>
        X-MARC-Message: https://marc.info/?l=mutt-dev&m=171352201829360
        MIME-Version: 1
        Content-Type: multipart/mixed; boundary="--VlyiQqPR0XvZgf2n"


        --VlyiQqPR0XvZgf2n
        Content-Type: text/plain; protected-headers=v1; charset=utf-8
        Content-Disposition: inline
        Content-Transfer-Encoding: quoted-printable
        Date: Fri, 19 Apr 2024 12:22:49 +0200
        From: Alejandro Colomar <a...@kernel.org>
        To: mutt-dev@mutt.org
        Subject: Re: Message security; protected header fields

        Hi Kevin,

        On Fri, Apr 19, 2024 at 11:43:20AM +0800, Kevin J. McCarthy wrote:
        > On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
        > > However, I'd like to point out that mutt added basic support for
        > > Protected Headers in the 2.0 release, following the Autocrypt 
project
        >=20
        > Ah, sorry, it was originally added in the 1.12 release (5/2019)!  The 
2.0
        > release added additional headers to the list and made some other 
tweeks.

        BTW, was there any discussion about it when it was added?  It would be
        interesting to link to it when adding the code to neomutt(1).

        I've found the release notes, the UPDATING file, and the commit, so far:

        -  <http://mutt.org/relnotes/2.0/>
        -  
<https://gitlab.com/muttmua/mutt/-/commit/82b5c697e935ffe40b833e150aa79f=
        d3cb27a20c>

        Cheers,
        Alex

        --=20
        <https://www.alejandro-colomar.es/>

        --VlyiQqPR0XvZgf2n
        Content-Type: application/pgp-signature; name="signature.asc"

        -----BEGIN PGP SIGNATURE-----

        iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmYiRfkACgkQnowa+77/
        2zJWYg/+P674OW7FbrKN+6MDIi+mrN73CA7bjsvdSBX39240AsH2wBwTLZKYdNBM
        lEsl6+VZE4qpUJih/pA2CnlxuyuKCWDCygEaev3uNHruGlL7B2dTpRHjKQFgpRtT
        QvU/ysW8nn+zV48nQDXKkNVlqRsW/5j82t+yBv7JbkIHcmBWcGnf7f02Kx8uKgJe
        5IemO6dSKEC3Ue5dvfIebCHNtF7k+B5BkNNUAPwatuWgC2+QQ69OySJWr4V4dZKt
        ksdVdovErXt3Of7S2HobFd0hZ5dmGeI10bKAPWv8+aX91TCaywAW5o8UHgkmDijH
        H/X4/holKhRA4RgG9gAhB3yXTrtyzWEX4FUnCPDi6kaSNvQ2KDBFuaj3lkz17Nfh
        eq7cwwvFcR2HFwgCNOWrAQNSOMsfsmd6BcP4cIRjwlBTBQIrTghtS8+YOZPxFrpQ
        GvHDvXDpAx7Xq3nGsAYpCfD1YxZGozs45Nc5jzk5XoopVZpQrHFLCTNOaW+ZzSWz
        tqBnJjF3cGSEr2FjqK/ArfGmYc7eMFl5ghO3ByBVAw+KVU8DWJyiW5z3pZOuvUuR
        OGcH8dWukyaVYE9oMyrDAdbcf7yHK4yXRZEYnZSooiOBrNCJNZ/T7bqcobeTp2kT
        rCVqwL5BgeSpyHAyy2OHs9CPPPLPZhXDuWILCUVC7F5Z4RJ3vaw=
        =oUWc
        -----END PGP SIGNATURE-----

        --VlyiQqPR0XvZgf2n--

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature

Reply via email to