Browse Source

approved by Alexey

master
Bernie Hoeneisen 1 year ago
parent
commit
d723592abc
1 changed files with 211 additions and 75 deletions
  1. +211
    -75
      misc/temp/draft-ietf-lamps-header-protection.mkd-am

+ 211
- 75
misc/temp/draft-ietf-lamps-header-protection.mkd-am View File

@ -35,7 +35,7 @@ informative:
# RFC3501: # IMAP #
RFC4949: # Internet Security Glossary #
# RFC4880: # OpenPGP #
RFC5321: # SMTP #
# RFC5321: # SMTP #
# RFC5490:
RFC6376: # DKIM #
RFC6409:
@ -217,8 +217,8 @@ mechanism is to be determined by the IETF LAMPS WG.
(cf. {{inner-msg-hf}}). The Inner Message must be the same on the
sending and the receiving side.
* Outer Message (OuterM): The Message as handed over to the Transport
or received from the Transport respectively. The Outer Message
* Outer Message (OuterM): The Message as handed over to the Submission
Entity or received from the last hop respectively. The Outer Message
normally differs on the sending and the receiving side (e.g. new
Header Fields are added by intermediary nodes).
@ -226,20 +226,18 @@ mechanism is to be determined by the IETF LAMPS WG.
at the receiving side. Typically this is the same as the Inner
Message.
* * Transport: The entity taking care of the transport of a Message
towards the receiver or from the sender.
<!-- Feedback KRB:
It's confusing to define transport as both an entity and process. I
realize that's exactly what it is, but it reads awkwardly. Suggest
"delivery", "transit", "transfer", or similar. The other uses of
"transport" are okay, just this opening sentence needs help.
-->
The Transport on the
sending side typically determines the destination recipients by
reading the To, Cc and Bcc Header Fields (of the Outer
Message). The Transport is typically implemented by an MTA (Mail
Transfer Agent).
* Submission Entity: The entity taking care of further processing of
the Message (incl. transport towards the receiver), after protection
measures have been applied to. It typically determines the
destination recipients by reading the To, Cc and Bcc Header Fields
(of the Outer Message).
Note: The Submission Entity varies among implementations, mainly
depending on the stage, where protection measures are applied to: It
could be e.g. a Message Submission Agent (MSA) {{RFC6409}} or
another (proprietary) solution. The latter is particularly relevant,
if protection is implemented as a plugin solution or for mixnet
networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
* Data Minimization: Data sparseness and hiding of all technically
concealable information whenever possible.
@ -295,33 +293,89 @@ PGP/MIME, etc.) used to achieve HP.
## Interactions {#interactions}
The following use cases assume that at least the sending side supports
Header Protection as specified in this document. Receiving sides that
support this specification are expected to be able to distinguish
between Messages that Header Protection -- as specified in this
document -- has been applied to and (legacy) Mail user Agents (MUAs)
not implementing this specification.
\[\[TODO: Verify once solution is stable and update last sentence \]\]
### Main Use Case {#uc-ia-main-use-case}
Both peers (sending and receiving side) fully support Header
Protection as specified in this document or the receiving side is at
least compliant with the MIME specification {{RFC2045}}, ff.;
cf. {{main-use-case}}.
Both peers (sending and receiving side) (fully) support Header
Protection as specified in this document.
The main use case is specified in {{main-use-case}}.
### Backward Compatibility
### Backward Compatibility Use Cases {#uc-ia-backward-compatibility-use-cases}
<!--
Alexey: why is the following text talking about not supporting MIME?
MIME was introduced almost 30 years ago!
Did you really mean "supports MIME, but doesn't support this specification"?
-->
The sending side fully supports Header Protection as specified in this
document, while the receiving side does not support the MIME
specification {{RFC2045}}, ff. correctly; see
{{backward-compatibility-use-case}}.
Regarding backwards compatibility the main distinction is based on
whether or not the receiving side conforms to MIME according to
{{RFC2046}}, ff., which in particular also includes Section 2 of
{{RFC2049}} on "MIME Conformance". In the following an excerpt of
paragraphs relevant in this context:
{::include ../shared/fence-line.mkd}
A mail user agent that is MIME-conformant MUST:
[...]
-- Recognize and display at least the RFC822 message
encapsulation (message/rfc822) in such a way as to
preserve any recursive structure, that is, displaying
or offering to display the encapsulated data in
accordance with its media type.
-- Treat any unrecognized subtypes as if they were
"application/octet-stream".
[...]
A user agent that meets the above conditions is said to be MIME-
conformant. The meaning of this phrase is that it is assumed to be
"safe" to send virtually any kind of properly-marked data to users
of such mail systems, because such systems will at least be able to
treat the data as undifferentiated binary, and will not simply
splash it onto the screen of unsuspecting users.
{::include ../shared/fence-line.mkd}
Note: The compatibility of legacy HP systems with this new solution,
and how to handle issues surrounding future maintenance for these
legacy systems, will be decided by the LAMPS WG.
#### Receiving Side MIME-Conformant {#uc-ia-bc-receiving-side-mime-conformant}
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. The receiving side is MIME-conformant according to
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}),
This use case is specified in {{receiving-side-mime-conformant}}.
Note: This case is expected to just work fine, if the sending side applies
specification for the main use case {{main-use-case}}.
\[\[TODO: Verify once solution is stable and update last sentence \]\]
#### Receiving Side Not MIME-Conformant {#uc-ia-bc-receiving-side-not-mime-conformant}
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. The receiving side is **not** MIME-conformant according
to {{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}})
either.
This use case is specified in {{receiving-side-not-mime-conformant}}.
## Protection Levels {#protection-levels}
The following protection levels need to be considered:
@ -383,11 +437,19 @@ receiving side is needed.
## Main Use Case {#main-use-case}
This section applies to the Interaction (cf. {{interactions}}), where
all involved parties (sending and receiving side) implement this
specification or the receiving side is at least compliant with the
MIME specification {{RFC2045}}, ff. (For backward compatibility cases
cf. {{backward-compatibility-use-case}}).
This section applies to the main use case, where both peers (sending
and receiving side) (fully) support Header Protection as specified
herein (cf. {{uc-ia-main-use-case}}).
Note: The sending side specification of the main use case is also
applicable to the cases, where the sending side (fully) supports
Header Protection as specified herein, while the receiving side does
not support this specification, but is MIME-conformant according to
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
{{uc-ia-bc-receiving-side-mime-conformant}})
Further backward compatibility cases are defined in
{{backward-compatibility-use-cases}}.
### MIME Format {#mime-format}
@ -513,6 +575,51 @@ Unlike the option described in {{option-smime-spec}}, this option does
not use a "message/RFC822" wrapper to unambiguously delimit the Inner
Message.
Before choosing this option, two issues must be assessed to ensure, no
interoperability issues result from it:
1. How current MIME parser implementations treat non-MIME Header
Fields, which are not part of the outermost MIME entity and not
part of a message wrapped into a MIME entity of media type
"message/rfc822", and how such messages are rendered to the user.
{{I-D.autocrypt-lamps-protected-headers}} provides some examples
for testing this.
2. MIME-conformance, i.e. whether or not this option is (fully)
MIME-conformant {{RFC2045}} ff., in particular also Section 5.1. of
{{RFC2046}} on "Multipart Media Type). In the following an excerpt
of paragraphs that may be relevant in this context:
{::include ../shared/fence-line.mkd}
The only header fields that have defined meaning for body parts
are those the names of which begin with "Content-". All other
header fields may be ignored in body parts. Although they
should generally be retained if at all possible, they may be
discarded by gateways if necessary. Such other fields are
permitted to appear in body parts but must not be depended on.
"X-" fields may be created for experimental or private
purposes, with the recognition that the information they
contain may be lost at some gateways.
{::include ../shared/fence-line.mkd}
{::include ../shared/fence-line.mkd}
NOTE: The distinction between an RFC 822 message and a body
part is subtle, but important. A gateway between Internet and
X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part
that contains an encapsulated message, the body of which is a
JPEG image. In order to represent the latter, the body part
must have "Content-Type: message/rfc822", and its body (after
the blank line) must be the encapsulated message, with its own
"Content-Type: image/jpeg" header field. The use of similar
syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which
parts actually are messages, a "digest" subtype is also
defined.)
{::include ../shared/fence-line.mkd}
The MIME structure of an Email message looks as follows:
{::include ../shared/fence-line.mkd}
@ -609,7 +716,7 @@ within any other protected part of the message:
The wrapper is a simple MIME Header Section followed by an empty line
preceding the Inner Message (inside the Outer Message Body). The media
type of the wrapper MUST be "message/RFC822" and SHOULD contain the
type of the wrapper MUST be "message/RFC822" and MUST contain the
Content-Type header field parameter "forwarded=no" as defined in
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambiguously
the Inner Message from the rest of the message.
@ -642,8 +749,9 @@ The following Header Fields are defined as the Essential Header Fields:
* Subject
Some of these Header Fields are required by RFC 5322 (e.g. Message-ID).
Furthermore, not including certain Header
Further processing by the Submission Entity normally depends on part
of these Header Fields, e.g. From and Date HFs are required by
{{RFC5322}}. Furthermore, not including certain Header
Fields may trigger spam detection to flag the message and/or
lead to user experience (UX) issues.
@ -714,14 +822,10 @@ MAY be obfuscated. Those may be replaced by e.g.
* To: Obfuscated <anonymous@anonymous.invalid>
<!--
Alexey: transport don't need access to To/Cc header fields, as this
information is carried separate at SMTP level. (Antispam engines
might need to access these.)
So the following statement (as written) is false:
Such implementations need to ensure that the Transport has access to
these Header Fields in clear text and is capable of processing those.
-->
Such implementations may need to ensure that the Submission Entity has
access to the content of these Header Fields in clear text and is
capable of processing those. This is particularly relevant, if
proprietary Submission Entities are used.
A use case for obfuscation of all Outer Message Header Fields is
mixnet networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
@ -778,10 +882,11 @@ from:
Legend:
* OuterM(S): Outer Message (OuterM) at sending side (before processing
by Transport)
* OuterM(S): Outer Message (OuterM) at sending side (before handing it
over to the Submission Entity)
* OuterM(R): Outer Message at receiving side (as received by Transport)
* OuterM(R): Outer Message at receiving side (as received by the last
hop, before decryption and/or signature verification is applied to)
* InnerM: Inner Message (that protection is applied to)
@ -816,7 +921,7 @@ Legend:
### Sending Side Message Processing {#sending-side-message-processing}
For a protected message the following steps are applied before a
message is handed over to the Transport:
message is handed over to the Submission Entity:
#### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1}
@ -859,7 +964,7 @@ the wrapper (as per {{RFC8551}}), and set the result to the message as
Outer Message Body.
The resulting (Outer) Message is then typically handed over to the
Transport.
Submission Entity.
\[\[ TODO: Example \]\]
@ -885,23 +990,52 @@ typically involves rendering it for the user.
Note: Further study is needed to determine whether or not the Outer
Message Header Section, as received from the Transport, is
Message Header Section, as received from the last hop, is
preserved for the user, and if so, how this is to be achieved.
## Backward Compatibility Use Case {#backward-compatibility-use-case}
## Backward Compatibility Use Cases {#backward-compatibility-use-cases}
### Receiving Side MIME-Conformant {#receiving-side-mime-conformant}
This section applies to the case where the sending side (fully)
supports Header Protection as specified in this document, while the
receiving side does not support this specification, but is
MIME-conformant according to {{RFC2045}},
ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
{{uc-ia-bc-receiving-side-mime-conformant}})
The sending side specification of the main use case
(cf. {#main-use-case}}) MUST ensure that receiving sides, that do not
support this specification, but are MIME-conformant according to
{{RFC2045}}, ff. can still recognize and display the Inner Message (or
rather the RUFM) in such a way as to preserve any recursive structure,
that is, displaying or offering to display the encapsulated data in
accordance with its media type (cf. {{RFC2049}}, Section 2).
\[\[TODO: Verify once solution is stable and update last sentence \]\]
### Receiving Side Not MIME-Conformant {#receiving-side-not-mime-conformant}
This section applies to the case where the sending side (fully)
supports Header Protection as specified in this document, while the
receiving side neither supports this specification and
**nor** is MIME-conformant according to {{RFC2045}}, ff.
(cf. {{uc-ia-backward-compatibility-use-cases}) and
{{uc-ia-bc-receiving-side-not-mime-conformant}}).
{{I-D.autocrypt-lamps-protected-headers}} describes a possible way to
achieve backward compatibility with existing S/MIME (and PGP/MIME)
implementations that predate this specification (Legacy Display). It
mainly focuses on email clients that do not render emails using header
protection (in a user friendly manner) and may confuse the user. While
this has been observed occasionally in PGP/MIME (cf. {{RFC3156}}), the
extent of this problem with S/MIME implementations is still
unclear. (Note: At this time, none of the samples in
{{I-D.autocrypt-lamps-protected-headers}} apply header protection as
specified in Section 3.1 of {{RFC8551}}, which is wrapping as Media
Type "message/RFC822".)
implementations that predate this specification and are not
MIME-conformant (Legacy Display) either. It mainly focuses on email clients
that do not render emails using header protection (in a user friendly
manner) and may confuse the user. While this has been observed
occasionally in PGP/MIME (cf. {{RFC3156}}), the extent of this problem
with S/MIME implementations is still unclear. (Note: At this time,
none of the samples in {{I-D.autocrypt-lamps-protected-headers}} apply
header protection as specified in Section 3.1 of {{RFC8551}}, which is
wrapping as Media Type "message/RFC822".)
Should serious backward compatibility issues with rendering at the
receiver be discovered, the Legacy Display format described in
@ -934,10 +1068,9 @@ This document requests no action from IANA.
The authors would like to thank the following people who have provided
helpful comments and suggestions for this document: Berna Alp, Claudio
Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol,
Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei
Chuang. <!-- TODO: add DKG either to authors or to Acknowledgments
-->
Luck, Daniel Kahn Gillmor, David Wilson, Hernani Marques, Krista
Bennett, Kelly Bristol, Robert Williams, Sofia Balicka, Steve Kille,
Volker Birk, and Wei Chuang.
--- back
@ -1001,12 +1134,9 @@ the message has to be cloned and adjusted depending on the recipient.
\[\[ RFC Editor: This section should be empty and is to be removed
before publication. \]\]
<!--
Alexey: it is compiant!
* Ensure "protected header" (Ex-Memory-Hole) option is (fully)
compliant with the MIME standard, in particular also {{RFC2046}},
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
-->
compliant with the MIME standard, in particular also {{RFC2046}},
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
* Decide on format of obfuscated HFs, in particular Date HF
({{obfuscation-outer-HF}})
@ -1019,9 +1149,6 @@ Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
* Should Outer Message Header Section (as received) be preserved for
the user? ({{receiving-side-step-2}})
* Do we need to take special care of HFs that may appear multiple
times, e.g. Received HF? ({{receiving-side-step-2}})
* Change adding Content-Type header field parameter "forwarded" from
SHOULD to MUST ({{wrapper}})?
@ -1037,6 +1164,15 @@ Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
* Decide on whether or not specification for more legacy HP
requirements should be added to this document
* Verify ability to distinguish between Messages with Header
Protection as specified in this document and legacy clients and
update {{interactions}} accordingly.
* Verify simple backward compatibility case (Receiving Side
MIME-Conformant) is working; once solution is stable and update
paragraphs in {#uc-ia-bc-receiving-side-mime-conformant}} and
{{receiving-side-mime-conformant}} accordingly.
* Improve definitions in {{protection-levels}}
* Privacy Considerations {{privacy-considerations}}


Loading…
Cancel
Save