Subject: [Spasm] Updating S/MIME handling of message/rfc822?

From: Wei Chuang <[email-masked]>
Date: Fri, 13 May 2016 16:09:00 -0700

Hi,

I would like to propose that draft-schaad-rfc5751-bis-00 further specify
handling message/rfc822 processing and specify how to merge message headers
from
decrypted/decoded non message/rfc822 types mime parts.  If we can clarify
header
processing this could provide significant improvement in privacy as
revealing
headers like subject can reveal a great deal about the content of the
message
and even metadata like date can be used with traffic analysis to reveal
hidden
recipients (Bcc).

There already exists "Securing Header Fields" as experimental RFC7508.  This
proposes that certain message header fields are signed and verified, and
optionally can replace or delete the field.  This provides a high degree of
flexibility and one approach would be to standard track this.  But this RFC
requires a fairly significant change to S/MIME / CMS processing steps, and
there
would be a deployed base that would find it difficult to interoperate with.
Another more feasibile approach is to clarify RFC5751 message/rfc822
language.
Likely this can get most of the header hiding benefit with a smaller change
to
CMS processing.

This proposes that if it is desirable to protect header integrity and
privacy
that message/rfc822 be used as specifed in RFC5280.  However this instead of
presenting both the outer header (original) and the inner header
(message/rfc822) part to the recipient, this proposes that when the CMS
processing is done, the inner headers in message/rfc822 update the outer
ones.
If there is a conflict between the inner and outer, then the inner header
replaces the outer ones.  Body content in message/rfc822 part replaces that
of
the parent as well.  Further there should a signed attribute that tells the
recipient to protect header integrity and privacy upon reply or forwarding
of
the message.  There also should be a capability specified as well.  Before
sending the message implementations would move these headers to the
message/rfc822 part, leaving those header fields unspecified in the sent
outer message header.

Compliant implementations should protect at least these message headers:
  Subject
  Date
  References
  Message-ID
  Keywords
  Original-XXX
This list is not meant to be exhaustive.  A complete list generated
from (http://www.iana.org/assignments/message-headers/message-headers.xhtml)
can
be done at a later time.  This list also makes no attempt to hide transport
artifacts like the trace headers as these are outside of the control of the
sender and recipient, or the sender and recipient headers as these are
needed by
transport.  (Other much more heavy weight approaches are better suited to
handle
hiding those headers)

thanks,
-Wei

---

From: Wei Chuang <[email-masked]>
Date: Thu, 19 May 2016 10:59:00 -0700

In case anyone is interested in this topic, I found this draft that
provides a better direction than what I had proposed.

https://tools.ietf.org/html/draft-melnikov-smime-header-signing-01

-Wei

On Fri, May 13, 2016 at 4:09 PM, Wei Chuang <[email-masked]> wrote:

> handling message/rfc822 processing and specify how to merge message
> headers from
> Likely this can get most of the header hiding benefit with a smaller
> change to
> CMS processing.
>
> replaces the outer ones.  Body content in message/rfc822 part replaces
> that of
> from (http://www.iana.org/assignments/message-headers/
> message-headers.xhtml) can

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 May 2016 09:57:42 +0100

Hi,

> On 19 May 2016, at 18:59, Wei Chuang <[email-masked]> wrote:
> 
> In case anyone is interested in this topic, I found this draft that provides a better direction than what I had proposed.
> 

Feel free to borrow text and fold it into other documents.

>> handling message/rfc822 processing and specify how to merge message headers from
>> decrypted/decoded non message/rfc822 types mime parts.  If we can clarify header
>> processing this could provide significant improvement in privacy as revealing
>> headers like subject can reveal a great deal about the content of the message
>> and even metadata like date can be used with traffic analysis to reveal hidden
>> recipients (Bcc).
>> 
>> requires a fairly significant change to S/MIME / CMS processing steps, and there
>> Another more feasibile approach is to clarify RFC5751 message/rfc822 language.
>> Likely this can get most of the header hiding benefit with a smaller change to
>> CMS processing.
>> 
>> This proposes that if it is desirable to protect header integrity and privacy
>> processing is done, the inner headers in message/rfc822 update the outer ones.
>> replaces the outer ones.  Body content in message/rfc822 part replaces that of
>> recipient to protect header integrity and privacy upon reply or forwarding of
>> from (http://www.iana.org/assignments/message-headers/message-headers.xhtml) can
>> sender and recipient, or the sender and recipient headers as these are needed by
>> transport.  (Other much more heavy weight approaches are better suited to handle
>> hiding those headers)
>> 
>> thanks,
>> -Wei
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm