Re: Message security; protected header fields

[Werner Koch]

On Thu,  9 May 2024 19:15, Derek Martin said:

> This is fine, though AFAICT it still suffers from the same problems as
> autocrypt:  

as well as attaching keys to a mail and the still common way to pick a
key from a keyserver.   Sure you should not trust this key but it allows
to start encryption sooner.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Mon, May 13, 2024 at 10:10:50AM GMT, Derek Martin wrote:
> On Fri, May 10, 2024 at 02:16:12AM +0200, Eike Rathke wrote:
> > If you can't trust but need to, then verify. The fingerprint over
> > a trusted channel. This has been part of PGP since the beginning.
> 
> Indeed, but that's what I've been saying.  The use of autocrypt (or
> similar features) downplays the need for this, and encourages naive
> users to skip this important step.

Just to clarify, the feature I'm proposing was designed by autocrypt
people (in parallel to me), but is orthogonal to it.  It's not related
at all, and doesn't encourage skipping this important step.  I'm myself
not an autocrypt user, and agree with you on that.

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Fri, May 10, 2024 at 02:16:12AM +0200, Eike Rathke wrote:
> Hi,
> 
> On Thursday, 2024-05-09 19:15:59 -0400, Derek Martin wrote:
> 
> > Probably fine for preventing casual eavesdropping, but for genuinely
> > sensitive applications, should not be considered good enough, unless
> > I'm missing some important detail...
> 
> If you can't trust but need to, then verify. The fingerprint over
> a trusted channel. This has been part of PGP since the beginning.

Indeed, but that's what I've been saying.  The use of autocrypt (or
similar features) downplays the need for this, and encourages naive
users to skip this important step.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Eike Rathke]

Hi,

On Thursday, 2024-05-09 19:15:59 -0400, Derek Martin wrote:

> Probably fine for preventing casual eavesdropping, but for genuinely
> sensitive applications, should not be considered good enough, unless
> I'm missing some important detail...

If you can't trust but need to, then verify. The fingerprint over
a trusted channel. This has been part of PGP since the beginning.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Wed, May 08, 2024 at 03:49:12PM +0200, Werner Koch wrote:
> Hi!
> 
> Thanks for the summary.  I fully agree add these 2 cents:

Thanks.

> In particular using a fixed subject is not going to work in any real
> business because you are not able to ignore mails.  For my part, I even
> use a auto-responder to tell that mails with a three-dot subject are
> ignored.

Indeed.

> There is a simpler method than autocrypt to initially convey a key.  If
> you can't MIME-attach it, include your key in the signature (gpg's
> --include-key-block).  This is what S/MIME does for decades.  If you
> don't have the recipient's key (i.e. no Web Key Directory), signing the
> first message allows the recipient to reply encrypted.

This is fine, though AFAICT it still suffers from the same problems as
autocrypt:  

 - trusting authentication data from an unknown/unverified source
 - MITM

[Arguably these are really the same problem.]

Probably fine for preventing casual eavesdropping, but for genuinely
sensitive applications, should not be considered good enough, unless
I'm missing some important detail...

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Steffen Nurpmeso]

Werner Koch wrote in
 <875xvoza5j@jacob.g10code.de>:
 |Thanks for the summary.  I fully agree add these 2 cents:
 |
 |In particular using a fixed subject is not going to work in any real
 |business because you are not able to ignore mails.  For my part, I even
 |use a auto-responder to tell that mails with a three-dot subject are
 |ignored.
 |
 |There is a simpler method than autocrypt to initially convey a key.  If
 |you can't MIME-attach it, include your key in the signature (gpg's
 |--include-key-block).  This is what S/MIME does for decades.  If you
 |don't have the recipient's key (i.e. no Web Key Directory), signing the
 |first message allows the recipient to reply encrypted.

That is the real thing!  That should be made a standard feature in
PGP, only the plain key without any Web of Trust noise, it is so
easy for S/MIME, even my one can simply use *SSL library provided
standard interfaces to take that and save it somewhere.
(And, to me, a real DNSSEC-secured DNS entry that can easily be
grasped by anyone, like the DKIM TXT record.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Werner Koch]

Hi!

Thanks for the summary.  I fully agree add these 2 cents:

In particular using a fixed subject is not going to work in any real
business because you are not able to ignore mails.  For my part, I even
use a auto-responder to tell that mails with a three-dot subject are
ignored.

There is a simpler method than autocrypt to initially convey a key.  If
you can't MIME-attach it, include your key in the signature (gpg's
--include-key-block).  This is what S/MIME does for decades.  If you
don't have the recipient's key (i.e. no Web Key Directory), signing the
first message allows the recipient to reply encrypted.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Mon, Apr 29, 2024 at 10:53:38PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
>  |> 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.

Hopefully it was clear from context that I was talking about
Autocrypt, not header protection, despite botching the quoting.

> I *wholeheartly* agree!  S/MIME is so much better by concept!
> This is why i like the new approach most PGP people now use, in
> that they use a signed MIME multipart which includes the public
> key as an attachment.

But... no...  This isn't better.  In either case, the problem is that
the source of the trust data--the e-mail itself--is untrusted.  You
have to have some way to verify the identity and signature of the key
out of band.  If you don't, you can guarantee that only the person who
sent you the key can read what you write, but you can't guarantee the
recipient is who you think it is.

> For PGP there really should be better (ie: TXT-based; or like so)
> SMIMEA/OPENPGKEY DNS entries, because what else one can have?
> WKD, and HKPS.  I (and many others) use OpenPGP: and point via
> https:// --- which is totally absurd given that the entire HTTPS
> aka TLS community as it is of today uses CA pools that is based
> upon commercial supermans.  No.

The trust model that OpenPGP implements is actually quite good--it
lets users establish the web of trust, and it also kind of lets you
"rate" your trust of a key, and then you can use that to make a
decision about how sensitive the info you're sending is, and whether
or not the trust level you have of the key matches it.  The problem
is, in practice, hardly anyone uses encryption at all, and of those
that do, too many use it improperly.

Unfortunately, using encryption properly and effectively is rather
unavoidably inconvenient--it requires thought and care.  Surely that's
why it has not been, and probably never will be, widely adopted. :(
The kinds of solutions like DNS records are sort of OK, if you only
care about basic privacy, but ultimately all of those require trust in
a third party--unless you run all of your infrastructure yourself,
which most people can't. But That's not good enough for applications
where encryption is actually essential, and any feature designed to
make it more convenient can only weaken the protection it provides.
For example, your ISP can hijack my DNS records if you're using their
DNS servers.  MITM is a huge problem that OpenPGP solves, but only if
you use it properly.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Steffen Nurpmeso]

Derek Martin wrote in
 <20240429203624.ge19...@bladeshadow.org>:
 |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-protect\
 |> ion
 |> 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.

I *wholeheartly* agree!  S/MIME is so much better by concept!
This is why i like the new approach most PGP people now use, in
that they use a signed MIME multipart which includes the public
key as an attachment.

And, btw, i am in full support of the OpenPGP: header that can be
DKIM protected (plus by the "protected headers").  Unfortunately
that never made it to a standard.

  ...

For PGP there really should be better (ie: TXT-based; or like so)
SMIMEA/OPENPGKEY DNS entries, because what else one can have?
WKD, and HKPS.  I (and many others) use OpenPGP: and point via
https:// --- which is totally absurd given that the entire HTTPS
aka TLS community as it is of today uses CA pools that is based
upon commercial supermans.  No.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Derek Martin]

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. Martinhttp://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

Re: Message security; protected header fields

[ilf]

I don't have the time or the nerve to dig into all the details of this 
thread. But I want to add some history and context:


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/

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.


3. https://gitlab.com/muttmua/mutt/-/issues/28
4. https://gitlab.com/muttmua/mutt/-/issues/28#note_73670220
5. http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20190527/000953.html

Derek Martin:
I've never heard of Memory Hole, nor until this conversation had I 
heard of autocrypt.


Kevin implemented Autocrypt in 2019. The "Mutt 1.13 Release Notes" 
mention Autocrypt as very first item, including three screenshots. [6]


6. http://www.mutt.org/relnotes/1.13/


Virtually no one uses this feature


I use this feature. So do many people I know. I vote to keep it and 
improve it.


Once the IETF draft is an RFC, all relevant MUAs should support this. 
While the RFC is still being finalized, we have the opportunity to test 
it and suggest improvements. "We believe in rough consensus and running 
code."


--
ilf

If you upload your address book to "the cloud", I don't want to be in it.

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 26, 2024 at 01:19:44AM +0200, Alejandro Colomar wrote:
> Yeah, most people don't even use PGP

Exactly.  On top of that, you have to use one of the small handful of
clients that support it, and then (for at least some of those) you
have to turn it on.  Like I said, virtually no one.  Or more
precisely, an infinitessimally small percentage of e-mail users.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 25, 2024 at 07:03:48PM -0400, Derek Martin wrote:
> On Thu, Apr 25, 2024 at 11:07:30PM +0200, Alejandro Colomar wrote:
> > While I don't have proof that no clients have major breakage with these
> > header fields, I can say that the most important ones don't have major
> > breakage.
> 
> Who are you to decide what the most important clients are?  If my
> favorite mail client is impacted, then that's the most important
> client of all... TO ME.

The most prevalent, I should've said.  Sorry for the imprecise wording.

> > mutt(1) has been protecting many header fields for several years already
> > (not by default, but you could enable it), and nobody has ever reported
> > a bug, did any?  The night sky is still up there and didn't fall on our
> > heads.
> 
> Virtually no one uses this feature,

That you didn't know of this feature doesn't mean "virtually nobody uses
it".  Did you do any survey?  I used it since the very first month I
started using mutt(1).

thunderbird(1) also protects the Subject using this mechanism.

And most people with whom I exchange signed/encrypted mail do use this
feature (maybe because I co-maintain the shadow project, and we are a
niche group that have to handle mail discussing security vulnerabilities
under embargo, and we don't want to disclose the slightest clue of such
a bug; but we do use those features).

Yeah, most people don't even use PGP, but going from that to virtually
no one is a big stretch.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 25, 2024 at 11:07:30PM +0200, Alejandro Colomar wrote:
> While I don't have proof that no clients have major breakage with these
> header fields, I can say that the most important ones don't have major
> breakage.

Who are you to decide what the most important clients are?  If my
favorite mail client is impacted, then that's the most important
client of all... TO ME.

One of Mutt's longstanding core development principles is to stick to
the robustness principle (Postel's Law).  In particular "be
conservative in what you emit."  This is not that.  Kevin is the
maintainer, so he can do what he wants, but I think accepting this
feature violates Mutt's original development philosophy.

> mutt(1) has been protecting many header fields for several years already
> (not by default, but you could enable it), and nobody has ever reported
> a bug, did any?  The night sky is still up there and didn't fall on our
> heads.

Virtually no one uses this feature, so again, the lack of evidence is
all but meaningless.  But sticking to good software design principles
does matter, even in the absence of documented cases of nonconfirmity
to good software design principles causing actual problems.

> That's a bit contradictory to another section of the same RFC:

I've read the RFC, I know what it says.  I already noted in previous
messages that adding the headers is ALLOWED by the RFC.  But it
historically hasn't been something that is generally done, and just
because something CAN be done doesn't mean it SHOULD.  Any time you
change the input data to a program in an unexpected way, a bug is the
LIKELY consequence.  I gave some legitimate examples of the sorts of
bugs that are LIKELY due to this implementation due to its
implementers not expecting that behavior.

There have been two alternatives suggested that do not suffer from
this problem, or any other as far as I can tell.  Either of those
would seem obviously better, and while I have no use for them, I would
have no objection to them.  They don't even require a new standard
(although you certainly should draft and submit one anyway)--all the
specification required is already part of either RFC 822 or the MIME
standard RFCs...

You probably would need to register a new MIME type with IANA or
whatever, to distinguish the signature from that of the message body,
but I imagine that's easier than writing a whole new RFC and getting
it approved.

> I think RFC 2045/2.4 specifically allows that as an extension.

Allows it, technically, maybe... but it does not DEFINE it.

Particularly with regard to the content of messages it generates, Mutt
implements standards.  Or at least historically it did.  This is not
that.

> And the draft that has been mentioned here is the document for
> documenting the extension.

But again, it's not a standard, it's just a specification.  A standard
is a specification that has been reviewed and accepted by either a
designated standards authority, or by the associated community
generally.  This document is neither.


-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Steffen Nurpmeso]

Derek Martin wrote in
 <20240425215214.gb19...@bladeshadow.org>:
 |On Thu, Apr 25, 2024 at 10:22:16PM +0200, Steffen Nurpmeso wrote:
 |> You talk to the wrong person given that other people added that
 |> mechanism and put it into practical use.
 |
 |Yeah unfortunately, as Kevin admitted, this feature was never
 |discussed here when it was implemented, so those who care about any of
 |that are having the conversation now.
 |
 |But that doesn't matter... I was specifically responding to YOUR
 |point, which was a logical fallacy.  You seemed to be making a point
 |that implied that if you aren't aware of clients that are negatively
 |impacted, then it doesn't matter.  That's bad logic.

So i really have no time for neither bikeshedding nor nitpicking,
but i quoted the standard, and there seems to be no
misinterpretation possible, for a simple brain like mine.
In email there is the main header, and that is anything that is
known; unless the agent is MIME capable, then it can interpret
multipart and "individual"-part sections.  By themselves, or
recursively descending/unfolding (decryption etc).
Which, btw, mutt implements in the only sensible way (with an
object tree, last i looked).
In *no* way, unless explicitly enabled, can a MIME header
influence the main message header.

I want to remark and always say that i think it is an unfortunate
decision to implement DKIM and all that mess the way it is done,
since our forefathers went the
envelope-into-new-envelope-then-seak approach for centuries or
even milleniums, and if it would be like that, then we would have
no problem with signatures breaking because of mailing-list
footers or adjusted subjects, and all that.

 |There's a difference between bugs caused by the implementer of the
 |receiver failing to correctly implement what is normal and expected,
 |and bugs caused by the implementer of the sender intentionally
 |implementing behavior that is outside what is normal and expected.
 |The former affects only the user of that software.  The latter affects
 |everyone else but the user of that software (at least potentially).
 |Responsible developers should strive to avoid both, but the latter
 |clearly has a more serious impact on more people, and exactly the
 |wrong people.  It is the whole reason the robustness principle exists.
 |Outlook is famous for this sort of thing, and it's one of the reasons
 |people hate Microsoft/Outlook.  
 |
 |> (And regarding this -- i think this works out fine.  Except for
 |> dumb clients like mine which do not get the thing and do not map
 |> those headers into the place of the main ones.  Yet.)
 |
 |You have no proof that this is true, among the hundreds if not
 |thousands of e-mail clients that exist.  That is the nature of

Yeah, i can plug one together with python modules or rust or what
in a minute that satisfies you.  Maybe.

 |undefined behavior.  There's nothing special about that term in the
 |context of ISO C or otherwise.  And since there isn't any sort of
 |official standard, it's probably rather unlikely that the majority of
 |clients will ever addopt this.  You can't call them dumb for not
 |implementing a standard that doesn't exist.
 |
 |> You can expect anything in it is what is said.  Of course, MUAs
 |> which do not understand maximally visualize those header lines in
 |> addition to the main ones (what mine does), or totally ignore them
 |> (what i expect graphical ones to do).  That is not "undefined
 |> behaviour".
 |
 |These are not the only possibilities, since again, the behavior is
 |undefined.  Headers could be incorrectly repeated (which could lead to

No one cares unless the signature breaks.
That, in general, is a GUI problem, again.  And everybody,
especially the browser based ones, will not do the right thing
upon it, whatever this is.

For example, some years ago, the ("some") GNU people were sending
out emails with two from:s i think it was (i maybe have saved it
somewhere), it was deliberately wrong (i told them).  This was
against the standard.
The email infrastructure delivered it :)

 |additional bugs, since that also is outside the spec), the "wrong"
 |version of the header could be the one the client uses.  Or the
 |structure you're using to hold the headers could overflow, causing
 |memory corruption and/or crashes.  Etc..  Those things might be
 |unlikely or impossible to happen in the absence of the undefined
 |behavior.  It's hard to be robust against problems you didn't forsee,
 |on account of them being well outside the norm.
 |
 |Undefined behavior is... undefined.  When the input data deviates from
 |what is expected, any variety of resulting bugs is LIKELY.

Interesting run, anyway.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 25, 2024 at 10:22:16PM +0200, Steffen Nurpmeso wrote:
> You talk to the wrong person given that other people added that
> mechanism and put it into practical use.

Yeah unfortunately, as Kevin admitted, this feature was never
discussed here when it was implemented, so those who care about any of
that are having the conversation now.

But that doesn't matter... I was specifically responding to YOUR
point, which was a logical fallacy.  You seemed to be making a point
that implied that if you aren't aware of clients that are negatively
impacted, then it doesn't matter.  That's bad logic.

There's a difference between bugs caused by the implementer of the
receiver failing to correctly implement what is normal and expected,
and bugs caused by the implementer of the sender intentionally
implementing behavior that is outside what is normal and expected.
The former affects only the user of that software.  The latter affects
everyone else but the user of that software (at least potentially).
Responsible developers should strive to avoid both, but the latter
clearly has a more serious impact on more people, and exactly the
wrong people.  It is the whole reason the robustness principle exists.
Outlook is famous for this sort of thing, and it's one of the reasons
people hate Microsoft/Outlook.  

> (And regarding this -- i think this works out fine.  Except for
> dumb clients like mine which do not get the thing and do not map
> those headers into the place of the main ones.  Yet.)

You have no proof that this is true, among the hundreds if not
thousands of e-mail clients that exist.  That is the nature of
undefined behavior.  There's nothing special about that term in the
context of ISO C or otherwise.  And since there isn't any sort of
official standard, it's probably rather unlikely that the majority of
clients will ever addopt this.  You can't call them dumb for not
implementing a standard that doesn't exist.

> You can expect anything in it is what is said.  Of course, MUAs
> which do not understand maximally visualize those header lines in
> addition to the main ones (what mine does), or totally ignore them
> (what i expect graphical ones to do).  That is not "undefined
> behaviour".

These are not the only possibilities, since again, the behavior is
undefined.  Headers could be incorrectly repeated (which could lead to
additional bugs, since that also is outside the spec), the "wrong"
version of the header could be the one the client uses.  Or the
structure you're using to hold the headers could overflow, causing
memory corruption and/or crashes.  Etc..  Those things might be
unlikely or impossible to happen in the absence of the undefined
behavior.  It's hard to be robust against problems you didn't forsee,
on account of them being well outside the norm.

Undefined behavior is... undefined.  When the input data deviates from
what is expected, any variety of resulting bugs is LIKELY.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 25, 2024 at 03:02:14PM -0400, Derek Martin wrote:
> Absence of evidence fallacy.  For this to be a non-concern (logically
> speaking) you would need to prove that NO client has this problem.
> Proving a negative is not always impossible, but given the number of
> clients in existence, it's pretty impractical.
> 
> Now, how that leaves you IS NOT with conclusive proof that you should
> not do it this way... but rather a strong suggestion that IF you can
> find a good alternative that doesn't have the same potential weakness
> (nor other worse tradeoffs), choose that instead.

While I don't have proof that no clients have major breakage with these
header fields, I can say that the most important ones don't have major
breakage.

mutt(1) has been protecting many header fields for several years already
(not by default, but you could enable it), and nobody has ever reported
a bug, did any?  The night sky is still up there and didn't fall on our
heads.

I guess mutt(1) users interact with every other major provider regularly
even if in small numbers.

> But I'm repeating myself now.
> 
> > ok i have reread 2045 and it says [...]
> 
> Largely irrelevant, because of what it does NOT say...  For instance,
> it does not describe what the behavior should be if standard RFC 822
> headers appear BOTH in a mime header block AND in the actual message
> headers.  This is what's known as undefined behavior.  Therein lies
> the path to non-interoperability--which Mutt intends (or, at least has
> historically intended) to avoid.  I've already described how such a
> problem might arise in a previous message.  Avoid forseeable
> interoperability problems when possible.
> 
> Also, what the RFC does explicitly state is that headers in the MIME
> header block that do not begin with "content-" "CAN HAVE NO MEANING"
> [emph. mine], and "may be ignored."

That's a bit contradictory to another section of the same RFC:



Any sort of field may be present in the header of an entity, but
only those fields whose names begin with "content-" actually
have any MIME-related meaning.  Note that this does NOT imply
thay they have no meaning at all -- an entity that is also a
message has non-MIME header fields whose meanings are defined by
RFC 822.

Which clearly says they do have meaning; it's just that they don't have
MIME-related meaning.  Bascially I read that as saying that you can put
mostly whatever you want, and MIME won't care about it; it will have the
meaning that you or a different RFC want to assign to it.

>  It gives no indication that there
> would be an exception to those conditions for headers that are
> explicitly defined by RFC 822 (or its successors).  Therefore any
> processing of them that you do is at best ambiguous, i.e. again,
> undefined behavior, and at worst violates the spec (because processing
> them gives them meaning that the spec says they can not have).
> 
> Which of course isn't to say that the standard can't be extended or
> modified; but if you want to do that, then you should actually draft
> the standard extension and get it approved, well before asking clients
> whose central tenets include complying with standards (as Mutt's do)
> to implement such extensions.  The reasons to do that are to establish
> whether the relevant community even values the extension, and whether
> better alternatives may exist or be found.

I think RFC 2045/2.4 specifically allows that as an extension.  And the
draft that has been mentioned here is the document for documenting the
extension.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Steffen Nurpmeso]

Derek Martin wrote in
 <20240425190214.ga19...@bladeshadow.org>:
 |On Wed, Apr 24, 2024 at 01:07:10AM +0200, Steffen Nurpmeso wrote:
 |> Sirius via Mutt-dev wrote in
 |>|I would worry less about the users and more about breaking clients. The
 |>|method of "be liberal about what you receive and conservative about what
 |>|you send" is apt. Being standards-compliant is safe.
 |> 
 |> Ah, do you know about any one client which fails on headers it
 |> does not understand,
 |
 |Absence of evidence fallacy.  For this to be a non-concern (logically
 |speaking) you would need to prove that NO client has this problem.
 |Proving a negative is not always impossible, but given the number of
 |clients in existence, it's pretty impractical.

You talk to the wrong person given that other people added that
mechanism and put it into practical use.
(And regarding this -- i think this works out fine.  Except for
dumb clients like mine which do not get the thing and do not map
those headers into the place of the main ones.  Yet.)

 |Now, how that leaves you IS NOT with conclusive proof that you should
 |not do it this way... but rather a strong suggestion that IF you can
 |find a good alternative that doesn't have the same potential weakness
 |(nor other worse tradeoffs), choose that instead.
 |
 |But I'm repeating myself now.

Sure.  Anyhow it is plain that bugs are everywhere.
In January i have written a RFC 5322 parser and looked around
a bit (not mutt), and found not a single parser without problems.
Then since February DKIM, and here you are.
Also we have gained too many RFCs in the last one or two decades,
and every little one invents new rulesets, instead of building
upon either *822 or 2045, like the ones before them.  This
unfortunately even includes DKIM.

 |> ok i have reread 2045 and it says [...]
 |
 |Largely irrelevant, because of what it does NOT say...  For instance,
 |it does not describe what the behavior should be if standard RFC 822
 |headers appear BOTH in a mime header block AND in the actual message
 |headers.  This is what's known as undefined behavior.  Therein lies

You can expect anything in it is what is said.
Of course, MUAs which do not understand maximally visualize those
header lines in addition to the main ones (what mine does), or
totally ignore them (what i expect graphical ones to do).
That is not "undefined behaviour".

 |the path to non-interoperability--which Mutt intends (or, at least has
 |historically intended) to avoid.  I've already described how such a
 |problem might arise in a previous message.  Avoid forseeable
 |interoperability problems when possible.

You make problems when there are none.

 |Also, what the RFC does explicitly state is that headers in the MIME
 |header block that do not begin with "content-" "CAN HAVE NO MEANING"
 |[emph. mine], and "may be ignored."  It gives no indication that there
 |would be an exception to those conditions for headers that are
 |explicitly defined by RFC 822 (or its successors).  Therefore any
 |processing of them that you do is at best ambiguous, i.e. again,
 |undefined behavior, and at worst violates the spec (because processing
 |them gives them meaning that the spec says they can not have).

Not undefined behaviour.  In the sense of ISO C undefined at
least.  Their meaning is simply not defined in this context, so
you either ignore them or show them (in configurable parts), but
by no means would you treat them as a replacement to the main
header instances.  Where is the problem?

 |Which of course isn't to say that the standard can't be extended or
 |modified; but if you want to do that, then you should actually draft
 |the standard extension and get it approved, well before asking clients
 |whose central tenets include complying with standards (as Mutt's do)
 |to implement such extensions.  The reasons to do that are to establish
 |whether the relevant community even values the extension, and whether
 |better alternatives may exist or be found.

I think having a RFC which only defines that -- in the sense of
the Melnikov etc draft's i have posted, would be a good thing.
But these protected header duplicates have nothing to do with
autocrypt as such.
Unfortunately the S/MIME and PGP worlds seem to be enemies or
what, it would make very much sense to define this for both, and
say that in a signed message container header duplicates etc etc.
Imho, that is.

 |Derek D. Martinhttp://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.
 --End of <20240425190214.ga19...@bladeshadow.org>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Derek Martin]

On Wed, Apr 24, 2024 at 01:07:10AM +0200, Steffen Nurpmeso wrote:
> Sirius via Mutt-dev wrote in
>  |I would worry less about the users and more about breaking clients. The
>  |method of "be liberal about what you receive and conservative about what
>  |you send" is apt. Being standards-compliant is safe.
> 
> Ah, do you know about any one client which fails on headers it
> does not understand,

Absence of evidence fallacy.  For this to be a non-concern (logically
speaking) you would need to prove that NO client has this problem.
Proving a negative is not always impossible, but given the number of
clients in existence, it's pretty impractical.

Now, how that leaves you IS NOT with conclusive proof that you should
not do it this way... but rather a strong suggestion that IF you can
find a good alternative that doesn't have the same potential weakness
(nor other worse tradeoffs), choose that instead.

But I'm repeating myself now.

> ok i have reread 2045 and it says [...]

Largely irrelevant, because of what it does NOT say...  For instance,
it does not describe what the behavior should be if standard RFC 822
headers appear BOTH in a mime header block AND in the actual message
headers.  This is what's known as undefined behavior.  Therein lies
the path to non-interoperability--which Mutt intends (or, at least has
historically intended) to avoid.  I've already described how such a
problem might arise in a previous message.  Avoid forseeable
interoperability problems when possible.

Also, what the RFC does explicitly state is that headers in the MIME
header block that do not begin with "content-" "CAN HAVE NO MEANING"
[emph. mine], and "may be ignored."  It gives no indication that there
would be an exception to those conditions for headers that are
explicitly defined by RFC 822 (or its successors).  Therefore any
processing of them that you do is at best ambiguous, i.e. again,
undefined behavior, and at worst violates the spec (because processing
them gives them meaning that the spec says they can not have).

Which of course isn't to say that the standard can't be extended or
modified; but if you want to do that, then you should actually draft
the standard extension and get it approved, well before asking clients
whose central tenets include complying with standards (as Mutt's do)
to implement such extensions.  The reasons to do that are to establish
whether the relevant community even values the extension, and whether
better alternatives may exist or be found.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Steffen Nurpmeso]

Hello.

Apologizing for the very late reply..

Sirius via Mutt-dev wrote in
 :
 |In days of yore (Sat, 20 Apr 2024), Steffen Nurpmeso thus quoth: 
 |> Kurt Hackenberg wrote in
 |>|Agreed.
 |> 
 |> I do not, actually.  Especially since it already is actively used.
 |> The question always is "how do receivers act upon this", of
 |> course, and this especially means the graphical, even
 |> browser-based monsters which users cannot configure, more, which
 |> have uneducated -- or better say "unaware" -- user bases.
 |
 |I would worry less about the users and more about breaking clients. The
 |method of "be liberal about what you receive and conservative about what
 |you send" is apt. Being standards-compliant is safe.

Ah, do you know about any one client which fails on headers it
does not understand, instead of simply searching for the
separating empty line in between the header block and the
successive content?  I have not reread 2045-9, ... ok i have
reread 2045 and it says

  9.  Additional MIME Header Fields

 Future documents may elect to define additional MIME header fields
 for various purposes.  Any new header field that further describes
 the content of a message should begin with the string "Content-" to
 allow such fields which appear in a message header to be
 distinguished from ordinary RFC 822 message header fields.

This implies that ordinary header fields can be expected to occur,
unless someone who wants to read a standard supercorrect fails in
doing so.

 |> Those clients, and i do not even know how well GMail or Outlook
 |> (or Apple Mail) can deal with S/MIME or PGP signed or even
 ..
 |Outlook and Apple Mail are able to use S/MIME out of the box. GnuPG is
 |something you have to work on to get to a functioning state, but it is
 |possible. For GMail there is a browser-plugin called FlowCrypt that will
 |give you GnuPG encryption. For Apple Mail, using MacGPG will do the same.
 |Not sure about browser mail via icloud.com, but FlowCrypt should work
 |there too (I just have not tested it). Outlook and GnuPG I have not tried
 |to get working, but there is some GUI offering of GnuPG for Windows, so I
 |assume it is possible.

Interesting, thanks for the info.

 |>|I would like to hold off on this until the draft becomes an RFC, if \
 |>|it does.
 |
 |Agreed - though as Mutt can produce at least the Subject line this way
 |when signing messages, we can test different mail clients to see how they
 |behave. I will endeavour to test Mac Mail, Outlook (new) and web-UI for
 |Gmail, Outlook and Apple mail to see how they render it. I will also test
 |KMail.
 |
 |I do not envisage clients breaking, but never say never. Stranger things
 |have happened throughout history.
 |
 |-- 
 |Kind regards,
 |
 |/S
 --End of 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Sirius via Mutt-dev]

In days of yore (Sat, 20 Apr 2024), Steffen Nurpmeso thus quoth: 
> Kurt Hackenberg wrote in
>  |Agreed.
> 
> I do not, actually.  Especially since it already is actively used.
> The question always is "how do receivers act upon this", of
> course, and this especially means the graphical, even
> browser-based monsters which users cannot configure, more, which
> have uneducated -- or better say "unaware" -- user bases.

I would worry less about the users and more about breaking clients. The
method of "be liberal about what you receive and conservative about what
you send" is apt. Being standards-compliant is safe.

> Those clients, and i do not even know how well GMail or Outlook
> (or Apple Mail) can deal with S/MIME or PGP signed or even
> encrypted (hmm..) email,  would have to take and treat the secured
> headers as the real ones.  But, quite the opposite, you hear
> statements of participants on user complaints like "i cannot
> [click-]open your attachment" and such for PGP etc detached
> signatures etc etc etc.
> (You also hear "please use > for quoting, my mailer does not
> understand your |", even though the leading whitespace was the
> very first quotation method ever used (in a RFC), and is still
> standardized in POSIX .. whatever.)

Outlook and Apple Mail are able to use S/MIME out of the box. GnuPG is
something you have to work on to get to a functioning state, but it is
possible. For GMail there is a browser-plugin called FlowCrypt that will
give you GnuPG encryption. For Apple Mail, using MacGPG will do the same.
Not sure about browser mail via icloud.com, but FlowCrypt should work
there too (I just have not tested it). Outlook and GnuPG I have not tried
to get working, but there is some GUI offering of GnuPG for Windows, so I
assume it is possible.

>  |I would like to hold off on this until the draft becomes an RFC, if \
>  |it does.

Agreed - though as Mutt can produce at least the Subject line this way
when signing messages, we can test different mail clients to see how they
behave. I will endeavour to test Mac Mail, Outlook (new) and web-UI for
Gmail, Outlook and Apple mail to see how they render it. I will also test
KMail.

I do not envisage clients breaking, but never say never. Stranger things
have happened throughout history.

-- 
Kind regards,

/S

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Steffen,

On Sun, Apr 21, 2024 at 01:01:54AM +0200, Steffen Nurpmeso wrote:
> Steffen Nurpmeso wrote in
>  <20240420191646.ZD-tN3eo@steffen%sdaoden.eu>:
>  |Kurt Hackenberg wrote in
>  | :
>  ||I would like to hold off on this until the draft becomes an RFC, if \
>  ||it does.
>  | --End of 
> 
> But i thing we refer to different drafts now.  I think you are all
> talking about draft-autocrypt-lamps-protected-headers-02, whereas
> i was at draft-ietf-lamps-header-protection-20.txt, and i find
> that terribly and needlessly excessive.  Note it also talks about
> a future deprecation of any non-protected messages, which i find
> too anticipatory, and needlessly so, too.
> 
>   #?0|kent:rfc$ wc -l draft-autocrypt-lamps-protected-headers-02.txt
>   3864 draft-autocrypt-lamps-protected-headers-02.txt
>   #?0|kent:rfc$ wc -l draft-ietf-lamps-header-protection-20.txt
>   11200 draft-ietf-lamps-header-protection-20.txt

I thoroughly checked the autocypt one at the start of this discussion,
IIRC.  Then someone pointed to the ietf one, and after some simple
inspection and web search, I think it's the evolution of the other, so
my assumption was that the autocrypt one will never be standard.

But yes, I prefer the simpler autocrypt one.

> I mean, basically, isn't that just "duplicate the most important
> headers of RFC 5322 into the signed part", aka "move practically
> anything useful out of the main header, and place it within the
> encrypted first multipart" (aka as via S/MIME and the Melnikov
> draft) for generation, and "if you understand cryptographic
> signatures and decrypting, use any such headers as the main
> instances, and best if you somehow make that warp visible".
> Which makes up six lines in this email.
> The latter draft i find an overly complicated thing.
> Btw i find that in general the ~1.4 decades brought lots of overly
> messy complicated stuff in the email architecture (a bit like
> DNS), and i find over and over again that we can be very lucky
> that the old and good ones generated protocols which scale from
> a dozen boxes to a billion ones, which all these, let me make it
> plain, crappy new things will *never* deliver, i bet.

And as you, I don't like autocrypt either.  I get my keys by human
interaction, and have .gnupg tracked by git(1) for any modification.
But in this matter, I think this autocrypt draft was sane.

> A nice Sunday everybody, if you can.

Have a lovely Sunday!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20240420230154.HauOMF4V@steffen%sdaoden.eu>:
 ...
 |But i thing we refer to different drafts now.  I think you are all
 |talking about draft-autocrypt-lamps-protected-headers-02, whereas
 ...

And i want to reiterate that i myself dislike autocrypt as yet one
another way to shit (sorry) masses of unused data into email
headers.  I still think that if you really want to communicate
with one securely then the normal thing is to send an email and
ask for it.  I mean hey, you want to have *encrypted
communication* with another human person, right.  Puh.
Other than that you can lookup keys.
The problem is solely that this automated fetching is shit (sorry)
as of today, except for WKD maybe, and those hkps which still
function, or not at all for S/MIME, that easily.  (And not by
default on German passports, not the one, not the other, and not
fetchable via German DNSSECured DNS records either.)

And all those DNS records which have been invented are the very
same brainfuckers (sorry), because no normal and mentally sane
person can use them, as they require specific DNS record
formatting that those web interfaces that the mentioned persona
has to use do not offer this, and, i guess, will never support.

Compare this with the intellectual penetration of reality that the
old good ones have proven to have, again, by looking at the DKIM
standard.  All you need is a TXT record, and almost everyone will
be able to place this.  DKIM is a good standard.  I have my heavy
doubts on most others.  But that is just me, of course.

I mean, what a pity.  Give me DNSSEC, give me RFC 7250 raw TLS
keys and DKIM certs and some better sort of SMIMEA and OPENPGP
through it, instead of also this .well-known trashbin and CA
certificate pools (get rid of the root server keys altogether
maybe, how about [1] instead, even if US does not like it?),
and more through it.

  [1] https://wander.science/paper/2017_Wander_Rootless_DNS.pdf

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20240420191646.ZD-tN3eo@steffen%sdaoden.eu>:
 |Kurt Hackenberg wrote in
 | :
 ||On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote:
 ||>On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
 ||>> 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.
 ||>
 ||>This also seems like a perfectly cromulent approach, and again better
 ||>than the proposed one which puts nonstandard headers in a place where
 ||>no standard says they can be. [Or perhaps the correct wording would
 ||>be, "...which nonstandardly puts standard headers in a place where no
 ||>standard says they should be."]
 ||
 ||Are you both thinking of defining a new MIME type to hold only the 
 ||protected headers?  I thought of that.  It seems cleaner...I see no 
 ||mention of that in the draft we're talking about, not even to reject 
 ||it.  I suppose old mail readers wouldn't know what to do with that new 
 ||body part.  They might display it if it's a subtype of text.
 ||
 ||Turns out an earlier way to protect headers was added in S/MIME 3.1.  
 ||It puts the whole message, including the header section, in a body part 
 ||of type message/rfc822, and wraps a crypto body part around that.  So 
 ||the message contains a copy of itself, sort of.
 |
 |There is also draft-melnikov-smime-header-signing(-02 i have) on
 |top of this.

And RFC 7508.  (At around the very same time..., well.)

 ||The draft calls that mechanism "wrapped".  The draft wants to replace 
 ||that with this header-stuffing thing because "legacy" mail readers are 
 ||sometimes confused by the wrapped message.  The draft says 
 ||header-stuffing is less likely to confuse mail readers that never heard 
 ||of either scheme.
 |
 |Regarding the topic itself, i see those h"eaders duplicated into
 |the signature-protected MIME header"s more and more often, it
 |seems some mailers can this produce regulary for some time.
 |The MUA i maintain needs at least two more years to get there, but
 |all in all i would wish that this mechanism of header duplication
 |would become a RFC by itself, maybe someone should talk with
 |Daniel Kahn Gillmor, i think it was, to split that part out.
 |(I have not kept the draft locally after reading it.)
 |
 ||>MIME header blocks are for MIME-specific metadata; even if no mail
 ||>clients actually break due to this, it still feels gross.
 ||
 ||Agreed.
 |
 |I do not, actually.  Especially since it already is actively used.

..and because it most likely is then placed in multipart/
"container" MIME parts.  I just got one.  

  [-- #1.1 96/5400 --]
  Content-Language: en-US
  Content-Type: multipart/signed; micalg=pgp-sha256; 
protocol="application/pgp-signature"; 
boundary="HM80rgQvS20JTDutBozx04k9"

  [-- #1.1.1 69/4207 --]
  Content-Type: multipart/mixed; 
boundary="eXGghbDaVc6gdEfE02LEf8h1"; protected-headers="v1"
  From:  <@...org>
  To: @org
  Message-ID: 
  Subject: Re: ..ing
  References: <...>
  In-Reply-To: <...>

 |The question always is "how do receivers act upon this", of
 |course, and this especially means the graphical, even
 |browser-based monsters which users cannot configure, more, which
 |have uneducated -- or better say "unaware" -- user bases.

 |Those clients, and i do not even know how well GMail or Outlook
 |(or Apple Mail) can deal with S/MIME or PGP signed or even
 |encrypted (hmm..) email,  would have to take and treat the secured
 |headers as the real ones.  But, quite the opposite, you hear
 |statements of participants on user complaints like "i cannot
 |[click-]open your attachment" and such for PGP etc detached
 |signatures etc etc etc.
 |(You also hear "please use > for quoting, my mailer does not
 |understand your |", even though the leading whitespace was the
 |very first quotation method ever used (in a RFC), and is still
 |standardized in POSIX .. whatever.)
 |
 ||I would like to hold off on this until the draft becomes an RFC, if \
 ||it does.
 | --End of 

But i thing we refer to different drafts now.  I think you are all
talking about draft-autocrypt-lamps-protected-headers-02, whereas
i was at draft-ietf-lamps-header-protection-20.txt, and i find
that terribly and needlessly excessive.  Note it also talks about
a future deprecation of any non-protected messages, which i find
too anticipatory, and needlessly so, too.

  #?0|kent:rfc$ wc -l draft-autocrypt-lamps-protected-headers-02.txt
  3864 draft-autocrypt-lamps-protected-headers-02.txt
  #?0|kent:rfc$ wc -l draft-ietf-lamps-header-protection-20.txt
  11200 draft-ietf-lamps-header-protection-20.txt

I mean, basically, isn't that just "duplicate the most important
headers of RFC 5322 into the signed part", aka "move 

Re: Message security; protected header fields

[Steffen Nurpmeso]

Kurt Hackenberg wrote in
 :
 |On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote:
 |>On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
 |>> 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.
 |>
 |>This also seems like a perfectly cromulent approach, and again better
 |>than the proposed one which puts nonstandard headers in a place where
 |>no standard says they can be. [Or perhaps the correct wording would
 |>be, "...which nonstandardly puts standard headers in a place where no
 |>standard says they should be."]
 |
 |Are you both thinking of defining a new MIME type to hold only the 
 |protected headers?  I thought of that.  It seems cleaner...I see no 
 |mention of that in the draft we're talking about, not even to reject 
 |it.  I suppose old mail readers wouldn't know what to do with that new 
 |body part.  They might display it if it's a subtype of text.
 |
 |Turns out an earlier way to protect headers was added in S/MIME 3.1.  
 |It puts the whole message, including the header section, in a body part 
 |of type message/rfc822, and wraps a crypto body part around that.  So 
 |the message contains a copy of itself, sort of.

There is also draft-melnikov-smime-header-signing(-02 i have) on
top of this.

 |The draft calls that mechanism "wrapped".  The draft wants to replace 
 |that with this header-stuffing thing because "legacy" mail readers are 
 |sometimes confused by the wrapped message.  The draft says 
 |header-stuffing is less likely to confuse mail readers that never heard 
 |of either scheme.

Regarding the topic itself, i see those h"eaders duplicated into
the signature-protected MIME header"s more and more often, it
seems some mailers can this produce regulary for some time.
The MUA i maintain needs at least two more years to get there, but
all in all i would wish that this mechanism of header duplication
would become a RFC by itself, maybe someone should talk with
Daniel Kahn Gillmor, i think it was, to split that part out.
(I have not kept the draft locally after reading it.)

 |>MIME header blocks are for MIME-specific metadata; even if no mail
 |>clients actually break due to this, it still feels gross.
 |
 |Agreed.

I do not, actually.  Especially since it already is actively used.
The question always is "how do receivers act upon this", of
course, and this especially means the graphical, even
browser-based monsters which users cannot configure, more, which
have uneducated -- or better say "unaware" -- user bases.

Those clients, and i do not even know how well GMail or Outlook
(or Apple Mail) can deal with S/MIME or PGP signed or even
encrypted (hmm..) email,  would have to take and treat the secured
headers as the real ones.  But, quite the opposite, you hear
statements of participants on user complaints like "i cannot
[click-]open your attachment" and such for PGP etc detached
signatures etc etc etc.
(You also hear "please use > for quoting, my mailer does not
understand your |", even though the leading whitespace was the
very first quotation method ever used (in a RFC), and is still
standardized in POSIX .. whatever.)

 |I would like to hold off on this until the draft becomes an RFC, if \
 |it does.
 --End of 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Werner Koch]

Hi,

I only had a brief look into this thread but stumbled upon this:

> *7:   BCCs should be hidden recipients.

[BCCs shold be separate mails of course.]

Using a hidden recipient is a major hassle for everyone with more than a
single key and in particular when several smartcards.  As a BCC
recipient you would be forced to do trial decryption and swap smartcards
over and over.  This is the very reason why I once introduced the
--skip-hidden-recipients optin and franly I use it for years now and
disable it only when needed.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Werner,

On Sat, Apr 20, 2024 at 02:10:28PM +0200, Werner Koch wrote:
> Hi,
> 
> I only had a brief look into this thread but stumbled upon this:
> 
> > *7:   BCCs should be hidden recipients.
> 
> [BCCs shold be separate mails of course.]
> 
> Using a hidden recipient is a major hassle for everyone with more than a
> single key and in particular when several smartcards.  As a BCC
> recipient you would be forced to do trial decryption and swap smartcards
> over and over.  This is the very reason why I once introduced the
> --skip-hidden-recipients optin and franly I use it for years now and
> disable it only when needed.

Thanks for the feedback!  That would be my favourite approach as a user,
although as a programmer I wanted to avoid it, since it would need big
work.

Richard, I guess we should first change neomutt(1) to send separate
mails for BCC in non-encrypted mode, which will already be a pain, and
then probably the encrypted thing will follow.  AFAIK, it's sending a
single mail, isn't it?  That would already be an improvement, because at
the moment, since it sends a single message, I see no Bcc: field when
receiving a Bcc message, which makes me wonder why I receive them.
Having a separate mail in which the Bcc field is set would be a nicer
UX.

I'll put this thing at the end of the queue of things I want to do.  In
the meantime, users will have to live with the fact that BCC encrypted
mail leaks the BCCs.  :-)

> Salam-Shalom,

Have a lovely day!
Alex

>Werner
> 
> -- 
> The pioneers of a warless world are the youth that
> refuse military service. - A. Einstein

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Kevin,

On Sat, Apr 20, 2024 at 11:39:17AM +0800, Kevin J. McCarthy wrote:
> What I did do was a minimal implementation of the spec at the time, so that
> Mutt could read messages from other clients that started sending with a
> hidden Subject header, for interoperability.
> 
> Writing was not enabled by default, but when enabled, it did send most/all
> of the spec listed headers (at the time), again for interoperability.
> 
> Doing "things" with other headers or even displaying them would open a big
> can of worms, so I kept the implementation minimal on purpose.

Fair enough.

> I don't have an opinion on the future direction Mutt takes here.  It
> wouldn't be hard to rip out the existing implementation, or to extend it.
> 
> However, I'll just remind everyone (again) that I'm definitely on my way
> out, completely, of Mutt development.  I stopped being a maintainer a couple
> years ago, and my time available just keeps getting less and less.  :-( I
> just don't have the time to participate anymore, not to mention review
> patches.

And fair enough.  Thank you for your time!

> If others really want the project to continue, it would be good for
> someone(s) to start picking up the reins.

If anyone does, I'll come back when this is an official RFC (maybe later
this year) to send patches.  :-)

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kurt Hackenberg]

On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote:


On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:

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.


This also seems like a perfectly cromulent approach, and again better
than the proposed one which puts nonstandard headers in a place where
no standard says they can be. [Or perhaps the correct wording would
be, "...which nonstandardly puts standard headers in a place where no
standard says they should be."]


Are you both thinking of defining a new MIME type to hold only the 
protected headers?  I thought of that.  It seems cleaner...I see no 
mention of that in the draft we're talking about, not even to reject 
it.  I suppose old mail readers wouldn't know what to do with that new 
body part.  They might display it if it's a subtype of text.


Turns out an earlier way to protect headers was added in S/MIME 3.1.  
It puts the whole message, including the header section, in a body part 
of type message/rfc822, and wraps a crypto body part around that.  So 
the message contains a copy of itself, sort of.


The draft calls that mechanism "wrapped".  The draft wants to replace 
that with this header-stuffing thing because "legacy" mail readers are 
sometimes confused by the wrapped message.  The draft says 
header-stuffing is less likely to confuse mail readers that never heard 
of either scheme.



MIME header blocks are for MIME-specific metadata; even if no mail
clients actually break due to this, it still feels gross.


Agreed.

I would like to hold off on this until the draft becomes an RFC, if it does.

Re: Message security; protected header fields

[Kevin J. McCarthy]

On Fri, Apr 19, 2024 at 05:07:17PM -0400, Derek Martin wrote:

On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote:

On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.

Fair enough.


But--and I s'pose I may have just missed it--I don't recall seeing any
discussion of this feature on this list.  Learning of such things is
precisely why I'm on this list, so... I'm not sure whether it's better
(from my perspective) that I missed it, or if it never happened. =8^)


That's fair enough back.  I don't think I engaged the list in discussion 
of the change. :^)


What I did do was a minimal implementation of the spec at the time, so 
that Mutt could read messages from other clients that started sending 
with a hidden Subject header, for interoperability.


Writing was not enabled by default, but when enabled, it did send 
most/all of the spec listed headers (at the time), again for 
interoperability.


Doing "things" with other headers or even displaying them would open a 
big can of worms, so I kept the implementation minimal on purpose.


I don't have an opinion on the future direction Mutt takes here.  It 
wouldn't be hard to rip out the existing implementation, or to extend 
it.


However, I'll just remind everyone (again) that I'm definitely on my way 
out, completely, of Mutt development.  I stopped being a maintainer a 
couple years ago, and my time available just keeps getting less and 
less.  :-( I just don't have the time to participate anymore, not to 
mention review patches.


If others really want the project to continue, it would be good for 
someone(s) to start picking up the reins.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Fri, Apr 19, 2024 at 04:56:30PM -0400, Derek Martin wrote:
> You're missing the point:  All software has bugs.  This would be a
> bug, but it's forseeable that mailers would have this bug.  For
> example, if the header parser you implement differentiates where to
> put the headers it's parsed based on what the header is--i.e. standard
> header vs. mime header, it may add the header to the wrong object, and
> now you have two subjects, two from headers, etc...  They are both
> headers, valid headers, that should be treated as headers--it just got
> the context wrong based on the name.
>
> In most cases this bug would be completely innocuous--and perhaps even
> beneficial (e.g. because it simplified the parser)--because mime
> header blocks typically should not have RFC 822 headers in them.
> Except now you've added a reason why they might.  Depending on what
> the borked client does next, this could inject further broken e-mail
> into the thread causing problems for everyone on it.
> 
> Does this bug exist anywhere?  Does any similar bug exist anywhere?  I
> don't know, but it's forseeable that such bugs may exist.

Actually, I've seen this bug.  My mail server (migadu) inserted a header
field right after the From field.  Since mutt(1) (and neomutt(1) with my
patches) insert a From in the protected MIME part, migadu also a field
after that From, invalidating my signature.

They fixed the bug in a few minutes after my report.

All software has bugs, but that doesn't mean not to use software, nor
not improve them.  Just fix the bugs.

>  Should you
> always avoid implementing functionality that might interact with a
> bug?  No... but if you can find a better design that is far less
> likely to interact with bugs, you should probably use that instead.

Having the signature in a header means redesigning the whole crypto in
emails.  That's likely going to trigger many bugs too.  I see your point
but I'm not sure the alternative is definitely better.

> > already a decent time frame that other projects can do the same thing.
> > Moreover, Memory Hole, later autocrypt, and now the IETF proposed draft,
> > all use this mechanism.  So we can say it's de-facto standard, even if
> > it's not yet standard.
> 
> I don't think you can... I've never heard of Memory Hole, nor until
> this conversation had I heard of autocrypt.

$ MANWIDTH=72 man neomuttrc | grep -A22 crypt_protected_headers_read$
 crypt_protected_headers_read
Type: boolean
Default: yes

When  set,  NeoMutt will display protected headers ("Memory
Hole") in the pager, When set, NeoMutt  will  display  pro‐
tected  headers in the pager, and will update the index and
header cache with revised headers.

Protected headers are stored inside the encrypted or signed
part of an an email, to prevent  disclosure  or  tampering.
For  more information see https://github.com/autocrypt/pro‐
tected-headers Currently NeoMutt only supports the  Subject
header.

Encrypted messages using protected headers often substitute
the   exposed  Subject  header  with  a  dummy  value  (see
$crypt_protected_headers_subject).  NeoMutt will update its
concept of the correct subject after the message is opened,
i.e. via the  function.  If you reply to a
message before opening it, NeoMutt will end  up  using  the
dummy  Subject  header,  so  be sure to open such a message
first.  (Crypto only)

TBH, I don't know why it's called memory hole.  But it's what mutt(1)
uses.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote:
> On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> > However, saying that mutt adds those headers by accident or as a bug seems a
> > bit uninformed.
> 
> Fair enough.

But--and I s'pose I may have just missed it--I don't recall seeing any
discussion of this feature on this list.  Learning of such things is
precisely why I'm on this list, so... I'm not sure whether it's better
(from my perspective) that I missed it, or if it never happened. =8^)

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 10:10:13PM +0200, Alejandro Colomar wrote:
> Hi Derek,
> 
> On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote:
> > On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> > > 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.
> > 
> > This also seems like a perfectly cromulent approach, and again better
> > than the proposed one which puts nonstandard headers in a place where
> > no standard says they can be. [Or perhaps the correct wording would
> > be, "...which nonstandardly puts standard headers in a place where no
> > standard says they should be."]
> 
> How would a program differentiate between a body whose contents are
> header-field-like?

You're missing the point:  All software has bugs.  This would be a
bug, but it's forseeable that mailers would have this bug.  For
example, if the header parser you implement differentiates where to
put the headers it's parsed based on what the header is--i.e. standard
header vs. mime header, it may add the header to the wrong object, and
now you have two subjects, two from headers, etc...  They are both
headers, valid headers, that should be treated as headers--it just got
the context wrong based on the name.

In most cases this bug would be completely innocuous--and perhaps even
beneficial (e.g. because it simplified the parser)--because mime
header blocks typically should not have RFC 822 headers in them.
Except now you've added a reason why they might.  Depending on what
the borked client does next, this could inject further broken e-mail
into the thread causing problems for everyone on it.

Does this bug exist anywhere?  Does any similar bug exist anywhere?  I
don't know, but it's forseeable that such bugs may exist.  Should you
always avoid implementing functionality that might interact with a
bug?  No... but if you can find a better design that is far less
likely to interact with bugs, you should probably use that instead.

> already a decent time frame that other projects can do the same thing.
> Moreover, Memory Hole, later autocrypt, and now the IETF proposed draft,
> all use this mechanism.  So we can say it's de-facto standard, even if
> it's not yet standard.

I don't think you can... I've never heard of Memory Hole, nor until
this conversation had I heard of autocrypt.  Outlook's long line
parsing can be called a defacto standard, because it's used by
millions, perhaps even billions of users every day.  These ain't.

And even if they were, just like Outlook's long line parsing, defacto
standards are often very bad standards.

And also, autocrypt DOES NOT use existing standard headers, so it
doesn't put standard headers in the MIME block.  That's an important
distinction which would not trigger any bug like the one I described
above.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 09:58:42PM +0200, Alejandro Colomar wrote:
> I think these days MIME is not so frowned upon as it once was.  But you
> have a point.  patatt(5) actually implements an idea like yours for
> signing patches including header fields, precisely for avoiding MIME.

To be clear, I love MIME.  I'm not trying to avoid it, and I think
Will's suggestion using MIME is absolutely fine.  I'm suggesting that
the existing implementation pollutes MIME, which should be avoided, as
it presents an opportunity for existing MIME-compliant mail readers to
be confused by RFC 822/2822/5322 headers being present in MIME header
blocks, which is not something any standard even hints at.  I'm not
saying any such clients exist, but given the vast array of clients, it
would be a challenge to prove that none do.  It's just bad practice
and should be avoided.

[The MIME spec says non-MIME headers can be present and should be
ignored, but it doesn't address handling duplicates of standard
headers, and it likely wouldn't occur to past implementers of MIME
that someone would want to do this... it's essentially undefined
behavior.  In most cases it probably should be fine, as long as
implementers were careful; but it's going to depend on how message
parsing / MIME header block parsing is implemented in each client.]

For the record, if this is important to you, I'm also not saying you
shouldn't implement it.  Kevin hinted he wouldn't be too keen on
working on adding this to Mutt, which is pretty consistent with Mutt's
history--maintainers have always leaned pretty conservative about
accepting patches, and for good reason.  And especially so as Mutt is
in maintenance mode.  But there's no reason you can't create them and
make them available to anyone who wants this.  That's something that's
also been a part of Mutt development for decades--I and many others
have maintained patches for Mutt for extended periods, some of which
eventually made it in, many of which did not. I'd just note that, as
it would be a subset of people who use Mutt and use Mutt's encryption
features--already a fairly rarified group--I suspect the audience for
such patches will be quite small indeed...

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote:
> On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> > 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.
> 
> This also seems like a perfectly cromulent approach, and again better
> than the proposed one which puts nonstandard headers in a place where
> no standard says they can be. [Or perhaps the correct wording would
> be, "...which nonstandardly puts standard headers in a place where no
> standard says they should be."]

How would a program differentiate between a body whose contents are
header-field-like?  Header fields must go in a structured area.  MIME
was designed precisely for that purpose: allowing header fields in the
body of a message, by structuring the body to have other header areas.

The only viable alternative is the patatt(5) way: using the message
header, no need for MIME.  However, inertia seems to be using MIME.

> MIME header blocks are for MIME-specific metadata; even if no mail
> clients actually break due to this, it still feels gross.  Yes, the
> MIME spec says other fields can appear there and should be ignored (so
> long as they don't start with "content-") but having standard message
> headers in multiple places unexpectedly still runs the risk that
> insufficiently carefully implemented clients will get confused.

mutt(1) has been doing it since 2018.  That's not like 1970, but it's
already a decent time frame that other projects can do the same thing.
Moreover, Memory Hole, later autocrypt, and now the IETF proposed draft,
all use this mechanism.  So we can say it's de-facto standard, even if
it's not yet standard.

Cheers,
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 09:30:27PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
>  <20240419191717.ge2...@bladeshadow.org>:
>  ...
>  |Secondly, there is a standard mechanism for adding non-standard
>  |headers to e-mail:  use the string "X-" before the thing, and add it
> 
> Not anymore since RFC 6648.

Eh... as far as I can tell that RFC is routinely ignored.  But fine,
just omit the "X-" and make sure the field names are unique.  This is
still allowed by RFC 5322.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Fri, Apr 19, 2024 at 03:17:17PM -0400, Derek Martin wrote:
> On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> > Signing header fields sounds reasonable, but I don't entirely like an
> > implementation that puts a copy of them in the message body, to be covered
> > by GPG.  I'd prefer something more direct, that signs headers without
> > copying them or modifying the message body.
> 
> This makes a lot of sense to me (assuming that this feature has
> genuine practical value, of which I remain largely unconvinced).  
> 
> First off:  Is there an actual RFC for the existing protected header
> scheme?

I don't think so.  It's being considered for a standard, though.  Will
posted a link in this thread:


>  If not, someone really ought to actually draft one and submit
> it, so that more people than just a handful of interested users of
> a small selection of specific mailer software could provide comments
> on the Request For Comments...
> 
> Secondly, there is a standard mechanism for adding non-standard
> headers to e-mail:  use the string "X-" before the thing, and add it
> to the normal message headers.

Not standard anymore.  Talking of RFCs...  See
.  The title of which is:

   Deprecating the "X-" Prefix and Similar Constructs
in Application Protocols


> To the extent that this feature is
> useful, it would be just as useful for non-encrypted messages as for
> encrypted messages.  You could do something like this:
> 
> X-protected-header-key:  0x1234567...  # probably unnecessary, but
> might be interesting for confirmation?
> X-protected-headers: (A base64-encoded string representing the precise
> and complete contents of the headers which were signed)
> X-protected-headers-signature:  (the actual signature of the data made
> by the specified key)
> 
> The user could verify the signature of the signed headers, so long as
> the key is available and trusted.  The mailer could display and/or
> visually confirm the signed headers against the standard ones,
> ignoring white-space differences, etc..
> 
> This is not very well fleshed out, but it already strikes me as better
> than what Mutt currently does: 
> 
>   - it does not require even having MIME parts in such a message.



I think these days MIME is not so frowned upon as it once was.  But you
have a point.  patatt(5) actually implements an idea like yours for
signing patches including header fields, precisely for avoiding MIME.

>   - I don't love what Mutt is currently doing--it seems it has the
> potential to break existing clients which are not expecting
> message headers in the MIME header blocks.  A well-behaved client
> probably shouldn't break, but as we all know, not all software is
> well-behaved.  All mailers are expected to accept/ignore X-*
> headers.
>
> Also FYI, I removed the neo-mutt list from this post because I'm not a
> member and I don't cross-post; and also you probably don't need to
> include Werner separately, he's a longstanding member of this list. :)

Considering that this is a discussion for a patch set proposed to both
projects, I think cross-posting is fine, but okay.  I'll manually tell
later neomutt(1) developers about anything interesting.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> 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.

This also seems like a perfectly cromulent approach, and again better
than the proposed one which puts nonstandard headers in a place where
no standard says they can be. [Or perhaps the correct wording would
be, "...which nonstandardly puts standard headers in a place where no
standard says they should be."]

MIME header blocks are for MIME-specific metadata; even if no mail
clients actually break due to this, it still feels gross.  Yes, the
MIME spec says other fields can appear there and should be ignored (so
long as they don't start with "content-") but having standard message
headers in multiple places unexpectedly still runs the risk that
insufficiently carefully implemented clients will get confused.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Steffen Nurpmeso]

Derek Martin wrote in
 <20240419191717.ge2...@bladeshadow.org>:
 ...
 |Secondly, there is a standard mechanism for adding non-standard
 |headers to e-mail:  use the string "X-" before the thing, and add it

Not anymore since RFC 6648.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> Signing header fields sounds reasonable, but I don't entirely like an
> implementation that puts a copy of them in the message body, to be covered
> by GPG.  I'd prefer something more direct, that signs headers without
> copying them or modifying the message body.

This makes a lot of sense to me (assuming that this feature has
genuine practical value, of which I remain largely unconvinced).  

First off:  Is there an actual RFC for the existing protected header
scheme?  If not, someone really ought to actually draft one and submit
it, so that more people than just a handful of interested users of
a small selection of specific mailer software could provide comments
on the Request For Comments...

Secondly, there is a standard mechanism for adding non-standard
headers to e-mail:  use the string "X-" before the thing, and add it
to the normal message headers.  To the extent that this feature is
useful, it would be just as useful for non-encrypted messages as for
encrypted messages.  You could do something like this:

X-protected-header-key:  0x1234567...  # probably unnecessary, but
might be interesting for confirmation?
X-protected-headers: (A base64-encoded string representing the precise
and complete contents of the headers which were signed)
X-protected-headers-signature:  (the actual signature of the data made
by the specified key)

The user could verify the signature of the signed headers, so long as
the key is available and trusted.  The mailer could display and/or
visually confirm the signed headers against the standard ones,
ignoring white-space differences, etc..

This is not very well fleshed out, but it already strikes me as better
than what Mutt currently does: 

  - it does not require even having MIME parts in such a message.
  - I don't love what Mutt is currently doing--it seems it has the
potential to break existing clients which are not expecting
message headers in the MIME header blocks.  A well-behaved client
probably shouldn't break, but as we all know, not all software is
well-behaved.  All mailers are expected to accept/ignore X-*
headers.

Also FYI, I removed the neo-mutt list from this post because I'm not a
member and I don't cross-post; and also you probably don't need to
include Werner separately, he's a longstanding member of this list. :)


-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Will Yardley]

On Fri, Apr 19, 2024 at 06:51:20PM +0200, Alejandro Colomar wrote:
> > 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.

Got it. I was looking at the draft implementation, where it appeared
that the subject was in a single line within the actual body of the
message. That makes a lot more sense to me.

w

Re: Message security; protected header fields

[Alejandro Colomar]

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=171352201829360=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 
    Date: Fri, 19 Apr 2024 10:22:49 +
To: mutt-dev
Subject: Re: Message security; protected header fields
Message-Id: 
X-MARC-Message: https://marc.info/?l=mutt-dev=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 
To: mutt-dev@mutt.org
Subject: Re: Message security; protected header fields

Hi Kevin,

On Fri, Apr 19, 2024

Re: Message security; protected header fields

[Will Yardley]

On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> 
> DKIM already exists, and signs header fields.  It publishes a key
> through DNS, and so is used by the administrator of the sending domain
> rather than by the end user.  Is that acceptable?

Agree about DKIM, and about the general nastiness of putting headers in
the message body (though I guess they are trying to solve problems at
different layers; if I'm understanding the theoretical problem
correctly, DKIM would pass since it's getting signed after the point
where the message is received by the MTA?)

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).

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)

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 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, and in most
cases, probably can be handled via common sense.

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.

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.

/w

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.

Fair enough.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Alejandro Colomar]

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
> 
> 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:

-  
-  


Cheers,
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Kurt,

On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:
> 
> > I reported around a month ago a couple of security vulnerabilities to
> > neomutt(1), but which are also present in mutt(1) and every MUA
> 
> So the main security vulnerability is that a recipient can tamper with
> header fields, and then reuse the message in some way, perhaps resend it?
> And you propose to cryptographically sign certain headers to detect
> tampering?

Yes.  And as Kevin pointed out, mutt(1) is already doing this.  It just
doesn't show it in the receiving side (I can't understand why).  So, at
least someone else thought in the past that it was a good idea too.

> Signing header fields sounds reasonable, but I don't entirely like an
> implementation that puts a copy of them in the message body, to be covered
> by GPG.  I'd prefer something more direct, that signs headers without
> copying them or modifying the message body.
> 
> DKIM already exists, and signs header fields.  It publishes a key through
> DNS, and so is used by the administrator of the sending domain rather than
> by the end user.  Is that acceptable?
> 
> Email authentication: 
> 
> DKIM: 

I don't trust too much anything not covered by GPG.  And, as said, we
don't need to patch mutt(1) to add this protection.  Only to use it in
the receiving side, which should be simple.

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Kevin,

On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote:
> > BTW, now that I remember, while developing these things for neomutt(1),
> > I found that mutt(1) has a bug (?) by which it does actually protect
> > some header fields precisely in the way that I implemented them in
> > neomutt(1), with the difference that mutt(1) does it on accident.
> 
> As Derek mentioned, mutt is in maintenance mode.  I don't have much, if any,
> time available to address issues except for genuine crashes or
> vulnerabilities.

I can write the code, if you have the time to review it.  I've already
written it for neomutt(1), so I'd only need to adapt it a little bit.

> However, I'd like to point out that mutt added basic support for Protected
> Headers in the 2.0 release, following the Autocrypt project spec at the time
> . Since then, undoubtedly,
> they've advanced the proposed spec, but I haven't followed it.
> 
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.

Ahh, sorry.  I assumed it was by accident because it didn't make sense
to me that you protect headers but then don't display them.  I was
wrong; I've found that you protect them on purpose in mutt_protect().

Which makes me wonder: if you considered it good to protect them, why
not display them, as with the protected subject?  Did you forget?  What
good is a protected header that is not shown, nor validated?  Yeah, one
would be able to inspect the raw message to check if it contains the
headers, but meh.

So, we wouldn't need to add much to mutt(1).  If you want me to send the
patches, just let me know.

Have a lvoely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote:
> On Thu, Apr 18, 2024 at 11:59:29PM +0200, Alejandro Colomar wrote:
> > Protecting the recipients and the in-reply-to doesn't mean hiding it.
> > It means providing a copy inside the signed part, so that it can be
> > verified against tampering.  It's not about encrypting them.
> 
> You can already do this in mutt by using a script as your editor to
> parse the headers, add the info you want to the body, and then edit
> your message.  But it doesn't really guarantee what you want because
> as I already pointed out, the message headers may differ from the
> actual recipients for a variety of reasons (Bcc, forwarding, mailing
> lists, etc.).  It may indicate a difference--it does not guarantee
> that the difference is caused by tampering.  It most likely is not, so
> it will most likely mislead you.

Hmmm, thanks.  I'll take the mailing list case into account.  Bcc is not
in the protected fields that I implemented, for obvious reasons.  When
forwarding, you're creating a new message (like when replying), and it
gets a new signature; I don't think this issue applies.

> The message interception scenario is possible, but I think highly
> improbable, especially for the sort of people who are using Mutt and
> encryption--savvy users.  It requires the attacker have superuser
> access to the mail system somewhere between you and your genuine
> recipients, AND either be known to your recipients, or your recipients
> must have no idea who should be on the message.  The attacker needs to
> be able to prevent the delivery of the original, to have time to
> inject the bogus message.  And your recipients need to already have
> the attacker's public key and trust it, or be set up to automatically
> download and use untrusted public keys...  

Well, if you see that your friend already sent an encrypted message to
that key, that could help trust that key, at least temporarily.

It only needs a man in the middle, but if they target you, that's a
reasonable scenario, I think.

And if the message is not encrypted, but only signed, it's not even
necessary a man in the middle.  An attacker can search for messages of
yours in mailing lists (or talk to you to get a new one, so the date is
more recent), download them, edit the headers, and bounce.

> > BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
> > the Subject.  That's precisely why I wanted some agreement on this
> > outside of just neomutt(1).
> 
> How so?

I used thunderbird(1) for some time in the past (until 2023).  When you
receive an encrypted message created by mutt(1) and read it in
thunderbird(1), you only see the "..." subject.  You don't see the
actual subject.  Or maybe it was the other way around, I don't remember
well.

> > > 2. Many of these violate existing standards, or at least have no
> > >standard.  Standards exist for a reason--if you don't follow them,
> > >other people who don't happen to use the exact same client as you
> > >won't be able to interoperate.
> > 
> > I don't think so.  Again, I don't think you've understood the points.
> 
> For instance, if you rely on the in-body headers when they differ from
> the message headers, the other recipients' response behavior will
> differ from yours, because that is not how e-mail works.  The
> standards dictate that e.g. the reply-to header--not some random text in
> the message body--is the address that e-mail clients should send
> replies to.  So yes, it violates the spec.

Well, we could just add the warnings, and continue using the outer
headers.  It will be up to the user to decide if the warning is valid or
not.  Thanks for pointing these issues; that's precisely why I wanted
more review.

Thanks!

> 
> > Have a lovely night!
> 
> You too!

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kevin J. McCarthy]

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 


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.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kevin J. McCarthy]

On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote:
BTW, now that I remember, while developing these things for neomutt(1), 
I found that mutt(1) has a bug (?) by which it does actually protect 
some header fields precisely in the way that I implemented them in 
neomutt(1), with the difference that mutt(1) does it on accident.


As Derek mentioned, mutt is in maintenance mode.  I don't have much, if 
any, time available to address issues except for genuine crashes or 
vulnerabilities.


However, I'd like to point out that mutt added basic support for 
Protected Headers in the 2.0 release, following the Autocrypt project 
spec at the time . 
Since then, undoubtedly, they've advanced the proposed spec, but I 
haven't followed it.


However, saying that mutt adds those headers by accident or as a bug 
seems a bit uninformed.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kurt Hackenberg]

On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:


I reported around a month ago a couple of security vulnerabilities to
neomutt(1), but which are also present in mutt(1) and every MUA


So the main security vulnerability is that a recipient can tamper with 
header fields, and then reuse the message in some way, perhaps resend 
it?  And you propose to cryptographically sign certain headers to 
detect tampering?


Signing header fields sounds reasonable, but I don't entirely like an 
implementation that puts a copy of them in the message body, to be 
covered by GPG.  I'd prefer something more direct, that signs headers 
without copying them or modifying the message body.


DKIM already exists, and signs header fields.  It publishes a key 
through DNS, and so is used by the administrator of the sending domain 
rather than by the end user.  Is that acceptable?


Email authentication: 

DKIM: 

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote:
> The message interception scenario is possible, but I think highly
> improbable, especially for the sort of people who are using Mutt and
> encryption--savvy users.  It requires the attacker have superuser
> access to the mail system somewhere between you and your genuine
> recipients, AND either be known to your recipients, or your recipients
> must have no idea who should be on the message.  The attacker needs to
> be able to prevent the delivery of the original, to have time to
> inject the bogus message.  And your recipients need to already have
> the attacker's public key and trust it, or be set up to automatically
> download and use untrusted public keys...  

Also, FWIW, I've been using Mutt and encryption for almost 30 years,
and I haven't heard of a single case where the way Mutt handles
encrypted mail caused someone embarrassment or loss.  Not to say there
haven't been any, but... at least if there were, not high enough
profile to make it HERE.

And to be honest, it's been my experience that your recipients are
much more likely to leak the stuff you sent them encrypted, through
their own stupidity/carelessness than because of any flaw in Mutt.
And yes, that has happened to me.  Be very careful about relying on
encryption to save you.  You're probably almost always much better off
just not saying whatever you thought you should encrypt.

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote:
> BTW, now that I remember, while developing these things for neomutt(1),
> I found that mutt(1) has a bug (?) by which it does actually protect
> some header fields precisely in the way that I implemented them in
> neomutt(1), with the difference that mutt(1) does it on accident.

I don't know whether or not it's intentional, but it does seem to be a
bug to me...  The message headers do not belong in the MIME headers
section.  But also note that Mutt doesn't do anything with them,
including display them (at least not here).

>   $ mutt -v | head -n1
>   Mutt 2.2.12+68 (841caf1c) (2023-10-25)

Yeah, mine is a bit older. =8^)


-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 18, 2024 at 11:59:29PM +0200, Alejandro Colomar wrote:
> Protecting the recipients and the in-reply-to doesn't mean hiding it.
> It means providing a copy inside the signed part, so that it can be
> verified against tampering.  It's not about encrypting them.

You can already do this in mutt by using a script as your editor to
parse the headers, add the info you want to the body, and then edit
your message.  But it doesn't really guarantee what you want because
as I already pointed out, the message headers may differ from the
actual recipients for a variety of reasons (Bcc, forwarding, mailing
lists, etc.).  It may indicate a difference--it does not guarantee
that the difference is caused by tampering.  It most likely is not, so
it will most likely mislead you.

The message interception scenario is possible, but I think highly
improbable, especially for the sort of people who are using Mutt and
encryption--savvy users.  It requires the attacker have superuser
access to the mail system somewhere between you and your genuine
recipients, AND either be known to your recipients, or your recipients
must have no idea who should be on the message.  The attacker needs to
be able to prevent the delivery of the original, to have time to
inject the bogus message.  And your recipients need to already have
the attacker's public key and trust it, or be set up to automatically
download and use untrusted public keys...  

> BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
> the Subject.  That's precisely why I wanted some agreement on this
> outside of just neomutt(1).

How so?

> > 2. Many of these violate existing standards, or at least have no
> >standard.  Standards exist for a reason--if you don't follow them,
> >other people who don't happen to use the exact same client as you
> >won't be able to interoperate.
> 
> I don't think so.  Again, I don't think you've understood the points.

For instance, if you rely on the in-body headers when they differ from
the message headers, the other recipients' response behavior will
differ from yours, because that is not how e-mail works.  The
standards dictate that e.g. the reply-to header--not some random text in
the message body--is the address that e-mail clients should send
replies to.  So yes, it violates the spec.

> Have a lovely night!

You too!

-- 
Derek D. Martinhttp://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

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 11:59:29PM GMT, Alejandro Colomar wrote:
> Hi Derek,
> 
> On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
> >g. Protecting the recipients is problematic for potentially several
> >   reasons--it prevents people from interacting normally with
> >   threads and their recipients.  The SMTP envelope needs at least
> >   the recipient you're actually sending to in that specific SMTP
> >   session, and the MTA will add the recipient's address in a
> >   Received header, so hiding that at least is pointless.  But if
> >   Mutt added these features it would be the only client to do so
> >   (AFAIK) making it very difficult for anyone using any other
> >   client to deal with.  You couldn't simply "reply-all" to, well,
> >   reply to all...  And again, you can just send separate messages.
> >   And if you really don't want your recipients to know about each
> >   other, then you shouldn't be sending them the same message
> >   anyway!  Avoid any possibility of embarrassment or worse--send
> >   separate messages.
> 
> I don't think you've understood the issue at all.
> 
> Protecting the recipients and the in-reply-to doesn't mean hiding it.
> It means providing a copy inside the signed part, so that it can be
> verified against tampering.  It's not about encrypting them.
> 
> So, if I manage you to send me a message saying "Yeah, go ahead.", and
> I change the recipient and in-reply-to header fields, I could maybe
> convince someone that you said yes to a different thread.  Does that
> not look like a security problem to you?  Well, that's fine.
> 
> BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
> the Subject.  That's precisely why I wanted some agreement on this
> outside of just neomutt(1).
> 
> > 2. Many of these violate existing standards, or at least have no
> >standard.  Standards exist for a reason--if you don't follow them,
> >other people who don't happen to use the exact same client as you
> >won't be able to interoperate.
> 
> I don't think so.  Again, I don't think you've understood the points.

BTW, now that I remember, while developing these things for neomutt(1),
I found that mutt(1) has a bug (?) by which it does actually protect
some header fields precisely in the way that I implemented them in
neomutt(1), with the difference that mutt(1) does it on accident.

I use

$ mutt -v | head -n1
Mutt 2.2.12+68 (841caf1c) (2023-10-25)

See the reply that I sent you in the list archives, which I sent with
mutt(1), and you'll find the protected headers
<https://marc.info/?l=mutt-dev=171347742508069=mbox>:

    From mutt-dev  Thu Apr 18 21:59:29 2024
From: Alejandro Colomar 
Date: Thu, 18 Apr 2024 21:59:29 +
To: mutt-dev
Subject: Re: Message security; protected header fields
Message-Id: 
X-MARC-Message: https://marc.info/?l=mutt-dev=171347742508069
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--T/e8leAN/4bSvaex"


--T/e8leAN/4bSvaex
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Apr 2024 23:59:29 +0200
From: Alejandro Colomar 
To: mutt-dev@mutt.org, neomutt-de...@neomutt.org
Subject: Re: Message security; protected header fields

Hi Derek,

On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
>g. Protecting the recipients is problematic for potentially several


However, I don't see that in your message, which means that either this
bug doesn't reproduce with your configuration, or you use a different
version of mutt(1).  Still, I find it interesting that mutt(1) messages
will be protected even if you don't patch mutt(1) --at least in some
cases--.  However, you won't be able to benefit from those protections,
since you don't use those headers at all.

Have a lovely night!
Alex

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


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
>g. Protecting the recipients is problematic for potentially several
>   reasons--it prevents people from interacting normally with
>   threads and their recipients.  The SMTP envelope needs at least
>   the recipient you're actually sending to in that specific SMTP
>   session, and the MTA will add the recipient's address in a
>   Received header, so hiding that at least is pointless.  But if
>   Mutt added these features it would be the only client to do so
>   (AFAIK) making it very difficult for anyone using any other
>   client to deal with.  You couldn't simply "reply-all" to, well,
>   reply to all...  And again, you can just send separate messages.
>   And if you really don't want your recipients to know about each
>   other, then you shouldn't be sending them the same message
>   anyway!  Avoid any possibility of embarrassment or worse--send
>   separate messages.

I don't think you've understood the issue at all.

Protecting the recipients and the in-reply-to doesn't mean hiding it.
It means providing a copy inside the signed part, so that it can be
verified against tampering.  It's not about encrypting them.

So, if I manage you to send me a message saying "Yeah, go ahead.", and
I change the recipient and in-reply-to header fields, I could maybe
convince someone that you said yes to a different thread.  Does that
not look like a security problem to you?  Well, that's fine.

BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
the Subject.  That's precisely why I wanted some agreement on this
outside of just neomutt(1).

> 2. Many of these violate existing standards, or at least have no
>standard.  Standards exist for a reason--if you don't follow them,
>other people who don't happen to use the exact same client as you
>won't be able to interoperate.

I don't think so.  Again, I don't think you've understood the points.

> 3. Probably most importantly, Mutt is basically in maintenance mode,
>i.e. no new features.  So none of this is likely to get
>implemented, even if one of the developers happened to agree with
>you.

I was just suggesting.  If you don't like it, then it's fine.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:
> Hi mutt(1) and neomutt(1) developers!
> 
> I reported around a month ago a couple of security vulnerabilities to
> neomutt(1), but which are also present in mutt(1) and every MUA
> (probably, I didn't do an exhaustive research).

While I don't presume to speak for Kevin, or anyone with commit
access, here are my thoughts:

1. None of the issues you listed are security vulnerabilities.  I'm
   also fairly sure that anyone sophisticated enough to use Mutt AND
   make regular use of encryption is not going to be confused by any
   of the display-related issues you pointed out.  If you are going to
   use encryption, then it's incumbent upon you, the user, to
   understand how it works, what it protects, and what it does not
   protect.  It's definitely an advanced use case.
   
   a. If you don't want to expose the "real" subject--don't.  You have
  full control over what you put there.  Likewise, you can also
  write whatever you want in the body of the message to address
  that.

   b. There are valid reasons (e.g. Bcc) why the message may be
  encrypted to someone not on (your copy of) the headers.  By and
  large, as the recipient, that's none of your business.
  Presumably, the sender knows what's happening and that's what
  matters.

   c. Pretty much the same thing with a listed recipient to whom the
  message is NOT encrypted.

   d. The blank lines are for readability--a display-only concern--and
  displaying them has no actual impact on security.  If you have
  reason to do something with the actual encrypted body other than
  neatly displaying it for your reading pleasure, process the
  actual message body outside Mutt in whatever manner you care to.

   e. "Hidden" recipients:  If you want to hide your recipients from
  each other, just send a separate message.  I haven't ever needed
  to but presumably you can use Mutt's command line interface to
  script this, so it's probably actually pretty trivial to do that
  already.

   f. "phishing protection" -- First, in the context of encrypted
  messages, this doesn't seem like a legitimate concern.  You're
  going to know who your recipients are, and their keys, and this
  won't be a factor.  But recipients' (or senders') addresses
  which are not 8-bit clean need to be encoded anyway, according
  to RFC 6531, so just looking at the headers will already reveal
  that.

   g. Protecting the recipients is problematic for potentially several
  reasons--it prevents people from interacting normally with
  threads and their recipients.  The SMTP envelope needs at least
  the recipient you're actually sending to in that specific SMTP
  session, and the MTA will add the recipient's address in a
  Received header, so hiding that at least is pointless.  But if
  Mutt added these features it would be the only client to do so
  (AFAIK) making it very difficult for anyone using any other
  client to deal with.  You couldn't simply "reply-all" to, well,
  reply to all...  And again, you can just send separate messages.
  And if you really don't want your recipients to know about each
  other, then you shouldn't be sending them the same message
  anyway!  Avoid any possibility of embarrassment or worse--send
  separate messages.

   h. The rest are just minor display issues--preferences--and have
  nothing to do with security whatsoever AFAICT.

2. Many of these violate existing standards, or at least have no
   standard.  Standards exist for a reason--if you don't follow them,
   other people who don't happen to use the exact same client as you
   won't be able to interoperate.

3. Probably most importantly, Mutt is basically in maintenance mode,
   i.e. no new features.  So none of this is likely to get
   implemented, even if one of the developers happened to agree with
   you.
   
Personally, I would not be in support of the vast majority of what you
suggested.  Maybe the "hidden recipient" for Bcc, but again, avoid the
whole problem and send a separate message.  But the bulk of what
you're suggesting is a ton of work and extra complexity for really
very little or no genuine benefit, and potentially significant
interoperability problems.

-- 
Derek D. Martinhttp://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

Message security; protected header fields

[Alejandro Colomar]

Hi mutt(1) and neomutt(1) developers!

I reported around a month ago a couple of security vulnerabilities to
neomutt(1), but which are also present in mutt(1) and every MUA
(probably, I didn't do an exhaustive research).

Vulnerability reports:

-  
-  

I also sent a report to Debian and Red Hat security teams to issue a
couple of CVEs.  I haven't received a response from the security teams,
but I guess they're busy at the moment with xz.

Richard and a few other neomutt(1) developers have helped me discuss
and polish these features.

We created a page to discuss the security of messages, and have an
overview of how to address these issues, and a few smaller ones.

-  

This PR addresses both security vulnerabilities:

-  

There are other spin-offs of that discussion, including the following
issues and PRs:

-  
   (this was a debugging feature that led me to this rabbit hole)

-  
-  
-  

-  

-  

-  

-  
-  

-  

Although it's a draft, since I have written alternative patches in other
PRs.  All the details are in the discussion page.

You're all invited to discuss this thing before we merge the changes.
I'd love if mutt(1) would be interested in coordinating the patches,
since I'm myself a mutt(1) user.  I just started developing them for
neomutt(1) because it's more open to development.  If you are open to
(some of) these changes, I could adapt the patches for mutt(1) too.

Here's an overview of my initial idea, using ASCII art.  Please scroll
to the right of the screen to see it all.  I've removed some bits that
I've discarded.

Date: Sat, 30 Mar 2024 12:22:13 +0100
From: Alejandro Colomar*10
Reply-To: e...@example.com*10
To: a...@kernel.es
Cc: b...@example.com   *10
Subject: ...

[-- Begin encryption information --]  \
Recipient: RSA key, ID 1234123412341234   |
Recipient: RSA key, ID 5678567856785678   }-- Hide: 
$crypt_encryption_info = no
Recipient: RSA key, ID    *7  |
[-- End encryption information --]/

[-- Begin signature information --]
Good signature from: Alejandro Colomar 
aka: Alejandro Colomar 
aka: Alejandro Colomar Andres 
created: Sat Mar 30 12:22:13 2024
[-- End signature information --]

[-- Warning: the header field 'Reply-To' has been tampered with --]  *11
[-- Warning: the header field 'Sender' has been tampered with --]
[-- Warning: the header field 'Mail-Followup-To' has been tampered with --]
[-- Warning: the header field 'X-Original-To has been tampered with --]
[-- Warning: the header field 'To' has been tampered with --]
[-- Warning: the header field 'In-Reply-To' has been tampered with --]

[-- The following data is PGP/MIME signed and encrypted --]   *3
From: Alejandro Colomar*8  \ \
Sender: f...@foo.com   | |
Reply-to: f...@foo.com }-|-{- Weed: 
weed && _protected_headers_weed = yes
Mail-Followup-To: f...@foo.com | |  \- 
Don't send: $crypt_protected_headers_write = no
X-Original-To: f...@foo.com| |
To: f...@foo.com   | |
Cc: b...@example.com   | }-- Hide: 
$crypt_protected_headers_read = no
Subject: Foo  | |
In-Reply-To: <...>*9  / |
  *4/
Body body
body body body
body
[-- End of PGP/MIME signed and encrypted data --] *3


*3:   No gratuituous blanks after the begining or before the ending
  [-- ... --] markers.

*4:   Blank line is part of this block. This one is meaningful, and
  should be printed if the header area is printed; even if the
  header area has 0 fields!

*6:   We should default to protecting these fields in outbound email.
  Not doing so is a security risk with no benefits (other than maybe
  repudiating one's own signed mail).

*7:   BCCs should be