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

[Wei Chuang <[e-mail]>]

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 <[e-mail]> wrote:

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