Subject: [lamps] Problems with the Abstract and Introduction of draft-ietf-lamps-header-protection-00

From: Russ Housley <[email-masked]>
Date: Thu, 23 Jul 2020 11:39:36 -0400

I really do not like the Abstract and Introduction of this Internet-Draft.

ABSTRACT

RFC 8551 says:

   In order to protect outer, non-content-related message header fields
   (for instance, the "Subject", "To", "From", and "Cc" fields), the
   sending client MAY wrap a full MIME message in a message/rfc822
   wrapper in order to apply S/MIME security services to these header
   fields.  It is up to the receiving client to decide how to present
   this "inner" header along with the unprotected "outer" header.

   When an S/MIME message is received, if the top-level protected MIME
   entity has a Content-Type of message/rfc822, it can be assumed that
   the intent was to provide header protection.  This entity SHOULD be
   presented as the top-level message, taking into account header
   merging issues as previously discussed.

We have discussed the problems with this approach, but that is not what the Abstract says.  It says:

   Privacy and security issues with email header protection in S/MIME
   have been identified for some time.  However, the desire to fix these
   issues has only recently been expressed in the IETF LAMPS Working
   Group.  The existing S/MIME specification is to be updated regarding
   header protection.

I would be much happier if the Abstract listed a few problems at a very high level with the approach in RFC 8551, and then said that this document addresses them.

INTRODUCTION

I do not understand the reason for the first paragraph of the Introduction to talk about DKIM, SPF, and DMARC.  This might come up much later in the Introduction if you want to make the point that some parts of the message headers can be integrity protected by non-S/MIME protocols, but it seems like a really strange way to start.

I think that the Introductions should state that the high-level objective is to provide end-to-end protection for header fields, and then say what the shortcomings are with the RFC 8551 mechanism, and then say how they are improved by this mechanism defined here.  Section 2 has place holders for some of this discussion, so it might be fine to point there.

Something about backward compatibility, even if it is a forward pointer, needs to be said in the Introduction.

Finally, the Introduction should point out that the mechanism is also applicable to PGP/MIME.

Russ

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 23 Jul 2020 22:44:13 +0200 (CEST)

Hi Russ

Thanks for your feedback.

I agree with you that the Abstract and Introduction Sections have lots of 
room for improvement. In fact, I focussed my limited time to the 
Specification and Use Case Sections, leaving other sections to be 
improved/fixed at some later stage.

Any text with suggestions to replace and/or improve the Abstract and 
Introduction Sections is welcome.

cheers,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology

On Thu, 23 Jul 2020, Russ Housley wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>