Browse Source

results of phonecall HM/HB

master
Bernie Hoeneisen 2 years ago
parent
commit
5851409ab6
1 changed files with 69 additions and 59 deletions
  1. +69
    -59
      ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd

+ 69
- 59
ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd View File

@ -135,8 +135,11 @@ determined by the IETF LAMPS WG.
optionally, by a Body; cf. {{RFC5322}}.
* Transport: The entity taking care of the transport of a Message
towards the receiver or from the sender. The Transport is
typically implemented in MTA (Mail Transfer Agent).
towards the receiver or from the sender. The Transport on the
sending side typically determines the destination recipients by
reading the To, Cc and Bcc Header Header Fields (of the Outer
Message). The Transport is typically implemented by an MTA (Mail
Transfer Agent).
* Header Field (HF): cf. {{RFC5322}} Header Fields are lines beginning
with a field name, followed by a colon (":"), followed by a field
@ -230,7 +233,7 @@ In the following a set of challenges to be addressed:
\[\[ TODO: enhance this section, add more items to the following \]\]
## Privacy
## Privacy {#privacy}
* Data Minimization, which includes data spareness and hiding all
technically concealable information whenever possible
@ -365,7 +368,7 @@ c) Encryption only
# Specification {#specification}
This section contains the specification for Header Protection in
S/MIME to update and clarify Section 3.1 of {{RFC8551}} (S/MIME
S/MIME to update and clarifies Section 3.1 of {{RFC8551}} (S/MIME
4.0). This specification is likely to be integrated into S/MIME at
some later stage.
@ -375,11 +378,15 @@ over this specification or parts of it.
This specification applies to the protection levels "signature &
encryption" and "signature only". It generally is NOT RECOMMENDED to send
a message with protection level "encryption only". On the other hand,
messages with protection level "encryption only" may arrive at the
messages with protection level "encryption only" might arrive at the
receiving side. While not targeted to protection level "encryption
only", this specification is assumed to also function for "encryption
only".
<!-- TODO: Clean up this section with proceeding section (redundant
statements)
-->
Note: It is for further study whether or not more guidance for
handling messages with protection level "encryption only" at the
receiving side is needed.
@ -492,9 +499,10 @@ An alternative Option (based on the former autocrypt "Memory Hole" approach)
to be considered, is described in
{{I-D.autocrypt-lamps-protected-headers}}.
That option emphasizes backward compatibility challenges to existing Mail
User Agents (MUAs) that do encryption, but are unaware of Header
Protection (see also {{backward-compatibility-use-case}}).
That option emphasizes backward compatibility challenges to existing
Mail User Agents (MUAs) that do encryption, but are unaware of Header
Protection as specified herein (see also
{{backward-compatibility-use-case}}).
That option suggests to use the media type "text/plain" to contain the
Inner Message (as opposed to "message/RFC822",
@ -538,6 +546,10 @@ nor to any other protected part of the message:
* Bcc
\[\[ TODO: Bcc handling needs to be further specified (see also
{{bcc-handling}}). Certain MUAs cannot properly decrypt messages
with Bcc recipients. \]\]
### Header Fields to Include to the Outer Message Header Section {#HF-include-outer}
@ -547,27 +559,30 @@ Header Section plus the Header Fields specified in
encryption or signature.
To maximize Privacy, it is strongly RECOMMENDED to follow the
principle of Data Minimization, which includes data spareness and
hiding all technically concealable information whenever possible.
principle of Data Minimization (cf. {{privacy}}).
However, the Outer Message Header Section SHOULD contain at least the
Essential Header Fields and MUST also contain the Header Fields of the
MIME Header Section part.
The Essential Header Fields are defined as the following Header
Fields:
The following Header Fields are defined as the Essential Header Fields:
* From
* To
* Cc (if present)
* Bcc (if present, see also {{HF-include-outer}} and {{bcc-handling}})
* Date
* Message-ID
* Subject
Not including those may trigger Spam Detection to flag the message as
Spam and/or lead to User Experience (UX) issues.
Most of these Header Fields are needed by the Transport (e.g. to
determine the destination). Furthermore, not including certain Header
Fields may trigger Spam Detection to flag the message as Spam and/or
lead to User Experience (UX) issues.
For further Data Minimization the values of these Header Fields MAY be
obfuscated, which is discussed further in {{obfuscation-outer-HF}}.
For further Data Minimization the values of some of these Header
Fields MAY be obfuscated, which is discussed further in
{{obfuscation-outer-HF}}.
The MIME Header Section part is the collection of MIME Header Fields
describing the following MIME structure as defined in {{RFC2045}}.
@ -594,17 +609,12 @@ message (using application/pkcs7-mime with SignedData):
Depending on the scenario, further Header Fields MAY be exposed in the
Outer Message Header Section, however - as stated above - this is NOT
RECOMMENDED unless justified. Such Header Fields may include
RECOMMENDED unless justified. Such Header Fields may include e.g.:
* Cc
* Bcc
* References
* Reply-To
* In-Reply-To
\[\[ Open Issue: Should Cc HF be included anyways, if present and if To HF
is not obfuscated? \]\]
#### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF}
If certain values of the following Outer Message Header Fields are
@ -612,34 +622,42 @@ obfuscated, those SHOULD assume the following values:
~~~
* From: "Obfuscated" anonymous@anonymous.invalid
* To: "Obfuscated" anonymous@anonymous.invalid
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
* Subject: ...
* Message-ID: <randomly generated ID>
* Message-ID: <new randomly generated ID>
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
~~~
Note: Alternative for Date: set to Monday 9am of the same week
Note: Should obfuscation of Subject be Default?
In any case, it MUST be ensured that the Transport has access to the
envelope information containing the source and destination(s) of a
message.
\[\[ TODO: Do we need this explanation about the envelope? \]\]
Note: Should obfuscation of Subject be default?
Note: It is for further study to what extent Header Field obfuscation
(adversely) impacts Spam Filtering.
\[\[ TODO: Determine whether also From, To, Cc could be obfucated, e.g.
* From: "Obfuscated" anonymous@anonymous.invalid
\]\]
\[\[ TODO: Determine whether mixnet capabilities \{\{pep.mixnets-url\}\}
should be described further here.
https://dev.pep.foundation/Mixnet/Messages
https://gitea.pep.foundation/juga/pEpPythonMixnet
https://dev.pep.foundation/Mixnet/
https://dev.pep.foundation/Mixnet/Mix%20networks
\]\]
### Header Fields to Exclude from the Outer Message Header Section {#HF-exclude-outer}
The Outer Message Header Section SHOULD NOT contain any non-essential
Header Fields. The essential Header Fields are defined in
{#HF-include-outer}.
{{HF-include-outer}}.
<!-- TODO: combine this and last section; same for Inner -->
### Message Processing
@ -658,23 +676,26 @@ The entity applying protection to a message must decide:
well as availability of cryptographic keys.
* Which Header Fields shall be part of the Outer Message Header
Section? This typically depends on local policy. By Default the
Section? This typically depends on local policy. By default the
Header Fields listed in {{HF-include-outer}} are part of the Outer
Message Header Section.
* Which of these Header Fields are to be obfuscated? This depends on
local policy and/or specific Privacy requirements of the user. By
Default no Header Field is obfuscated. (cf. {{obfuscation-outer-HF}})
default only the Subject Header Field is
obfuscated. (cf. {{obfuscation-outer-HF}})
##### Step 2: Compose the Outer Message Header Section {#sender-side-step-2}
Depending on the decision in {{sender-side-step-1}}, compose the Outer
Message Header Section. Note, that this also includes the necessary
MIME Header Section part for the following protection layer. Outer
Header Fields that are not obfuscated SHOULD contain the same values
as in the Original Message (except for MIME Header Section part, which
depends on the protection level selected in {{sender-side-step-1}}).
Message Header Section. (Note that this also includes the necessary
MIME Header Section part for the following protection layer.)
Outer Header Fields that are not obfuscated SHOULD contain the same
values as in the Original Message (except for MIME Header Section
part, which depends on the protection level selected in
{{sender-side-step-1}}).
##### Step 3: Apply Protection to the Original Message {#sender-side-step-3}
@ -737,28 +758,19 @@ this time, none of the samples in
specified in Section 3.1 of {{RFC8551}}, which is wrapping as Media
Type "message/RFC822".)
Should serious Backward Compatibly issues with rendering at the
receiver show up, {{I-D.autocrypt-lamps-protected-headers}} may serve
as a basis to mitigate those.
Should serious backward compatibility issues with rendering at the
receiver show up, the Legacy Display format described in
{{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to
mitigate those.
Another variant of backward compatibility has been implemented by pEp
{{I-D.pep-email}}, i.e. pEp Message Format 1.0. At this time pEp
{{I-D.pep-email}}, i.e. pEp Email Format 1.0. At this time pEp
has only been implementing PGP/MIME, but not yet S/MIME.
# Security Considerations
This document talks about UI considerations, including security
considerations, when processing messages protecting Header Fields.
One of the goals of this document is to specify UI for displaying such
messages which is less confusing/misleading for the end-user and thus
more secure.
This document does not define new protocols, and thus does not create
new security concerns in and of itself. Existing security concerns
addressed in S/MIME {{RFC8551}}, MIME {{RFC2045}}, and Email
{{RFC5322}} still apply to header fields and should be taken into
consideration.
\[\[ TODO \]\]
# Privacy Considerations
@ -791,7 +803,7 @@ Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.
# Additional information
## Stored Variants of Messages with Bcc
## Stored Variants of Messages with Bcc {#bcc-handling}
Messages containing at least one recipient address in the Bcc
header field may appear in up to three different variants:
@ -838,8 +850,6 @@ header field may appear in up to three different variants:
\[\[ RFC Editor: This section should be empty and is to be removed
before publication. \]\]
* Include CC by default/always to Outer HS?
* Decide on format of obfuscated HFs, in particular Date HF
* Do we need to mention something about the envelope (some HF may no


Loading…
Cancel
Save