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

Hi,

> On 19 May 2016, at 18:59, Wei Chuang <weihaw@google.com> wrote:
> 
> 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

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

> -Wei
> 
>> On Fri, May 13, 2016 at 4:09 PM, Wei Chuang <weihaw@google.com> 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
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm