rfc9788v4.txt | rfc9788.txt | |||
---|---|---|---|---|
skipping to change at line 143 ¶ | skipping to change at line 143 ¶ | |||
Content-Types | Content-Types | |||
6. Replying and Forwarding Guidance | 6. Replying and Forwarding Guidance | |||
6.1. Avoid Leaking Encrypted Header Fields in Replies and | 6.1. Avoid Leaking Encrypted Header Fields in Replies and | |||
Forwards | Forwards | |||
6.1.1. ReferenceHCP | 6.1.1. ReferenceHCP | |||
6.2. Avoid Misdirected Replies | 6.2. Avoid Misdirected Replies | |||
7. Unprotected Header Fields Added in Transit | 7. Unprotected Header Fields Added in Transit | |||
7.1. Mailing List Header Fields: List-* and Archived-At | 7.1. Mailing List Header Fields: List-* and Archived-At | |||
8. Email Ecosystem Evolution | 8. Email Ecosystem Evolution | |||
8.1. Dropping Legacy Display Elements | 8.1. Dropping Legacy Display Elements | |||
8.2. More Ambitious Default Header Confidentiality Policy | 8.2. More Ambitious Default HCP | |||
8.3. Deprecation of Messages Without Header Protection | 8.3. Deprecation of Messages Without Header Protection | |||
9. Usability Considerations | 9. Usability Considerations | |||
9.1. Mixed Protections Within a Message Are Hard to Understand | 9.1. Mixed Protections Within a Message Are Hard to Understand | |||
9.2. Users Should Not Have to Choose a Header Confidentiality | 9.2. Users Should Not Have to Choose a Header Confidentiality | |||
Policy | Policy | |||
10. Security Considerations | 10. Security Considerations | |||
10.1. From Address Spoofing | 10.1. From Address Spoofing | |||
10.1.1. From Rendering Reasoning | 10.1.1. From Rendering Reasoning | |||
10.2. Avoid Cryptographic Summary Confusion from the hp | 10.2. Avoid Cryptographic Summary Confusion from the hp | |||
Parameter | Parameter | |||
skipping to change at line 318 ¶ | skipping to change at line 318 ¶ | |||
considered in [RFC8551]. | considered in [RFC8551]. | |||
1.1.1. Problems with RFC 8551 Header Protection | 1.1.1. Problems with RFC 8551 Header Protection | |||
Several Legacy MUAs have difficulty rendering a message that uses | Several Legacy MUAs have difficulty rendering a message that uses | |||
RFC8551HP. These problems can appear on signed-only messages, as | RFC8551HP. These problems can appear on signed-only messages, as | |||
well as signed-and-encrypted messages. | well as signed-and-encrypted messages. | |||
In some cases, some MUAs cannot render message/rfc822 message | In some cases, some MUAs cannot render message/rfc822 message | |||
subparts at all, which is in violation of baseline MIME requirements | subparts at all, which is in violation of baseline MIME requirements | |||
as defined in Section 2 of [RFC2049]. A message using RFC8551HP is | as defined in requirement 6 of Section 2 of [RFC2049]. A message | |||
unreadable by any recipient using such an MUA. | using RFC8551HP is unreadable by any recipient using such an MUA. | |||
In other cases, the user sees an attachment suggesting a forwarded | In other cases, the user sees an attachment suggesting a forwarded | |||
email message that -- in fact -- contains the protected email message | email message that -- in fact -- contains the protected email message | |||
that should be rendered directly. In most of these cases, the user | that should be rendered directly. In most of these cases, the user | |||
can click on the attachment to view the protected message. | can click on the attachment to view the protected message. | |||
However, viewing the protected message as an attachment in isolation | However, viewing the protected message as an attachment in isolation | |||
may strip it of any security indications, leaving the user unable to | may strip it of any security indications, leaving the user unable to | |||
assess the cryptographic properties of the message. Worse, for | assess the cryptographic properties of the message. Worse, for | |||
encrypted messages, interacting with the protected message in | encrypted messages, interacting with the protected message in | |||
skipping to change at line 960 ¶ | skipping to change at line 960 ¶ | |||
delivery systems, some of which may reject, drop, or delay messages | delivery systems, some of which may reject, drop, or delay messages | |||
where all Header Fields are removed from the top-level MIME object. | where all Header Fields are removed from the top-level MIME object. | |||
Note that no representation of the HCP itself ever appears "on the | Note that no representation of the HCP itself ever appears "on the | |||
wire". However, the consumer of the encrypted message can see the | wire". However, the consumer of the encrypted message can see the | |||
decisions that were made by the sender's HCP via the HP-Outer Header | decisions that were made by the sender's HCP via the HP-Outer Header | |||
Fields (see Section 2.2). | Fields (see Section 2.2). | |||
3.1. HCP Definition | 3.1. HCP Definition | |||
In this document, we represent that Header Confidentiality Policy as | In this document, we represent that HCP as a function hcp: | |||
a function hcp: | ||||
* hcp(name, val_in) -> val_out: This function takes a Non-Structural | * hcp(name, val_in) -> val_out: This function takes a Non-Structural | |||
Header Field identified by name with the initial value val_in as | Header Field identified by name with the initial value val_in as | |||
arguments and returns a replacement Header Field value val_out. | arguments and returns a replacement Header Field value val_out. | |||
If val_out is the special value null, it means that the Header | If val_out is the special value null, it means that the Header | |||
Field in question should be removed from the set of Header Fields | Field in question should be removed from the set of Header Fields | |||
visible outside the Cryptographic Envelope. | visible outside the Cryptographic Envelope. | |||
In the pseudocode descriptions of various choices of HCP in this | In the pseudocode descriptions of various choices of HCP in this | |||
document, any comparison with the name input is done case- | document, any comparison with the name input is done case- | |||
skipping to change at line 1038 ¶ | skipping to change at line 1037 ¶ | |||
The purpose of the registry of HCPs is to facilitate HCP evolution | The purpose of the registry of HCPs is to facilitate HCP evolution | |||
and interoperability discussion among MUA developers and MTA | and interoperability discussion among MUA developers and MTA | |||
operators. | operators. | |||
(The example hypothetical HCP, hcp_example_hide_cc, described in | (The example hypothetical HCP, hcp_example_hide_cc, described in | |||
Section 3.1 above is deliberately not formally registered, as it has | Section 3.1 above is deliberately not formally registered, as it has | |||
not been evaluated in practice.) | not been evaluated in practice.) | |||
3.2.1. Baseline Header Confidentiality Policy | 3.2.1. Baseline Header Confidentiality Policy | |||
The most conservative recommended Header Confidentiality Policy only | The most conservative recommended HCP only provides confidentiality | |||
provides confidentiality for Informational Fields, as defined in | for Informational Fields, as defined in Section 3.6.5 of [RFC5322]. | |||
Section 3.6.5 of [RFC5322]. These fields are "only human-readable | These fields are "only human-readable content" and thus their content | |||
content" and thus their content should not be relevant to transport | should not be relevant to transport agents. Since most Internet | |||
agents. Since most Internet messages today do have a Subject Header | messages today do have a Subject Header Field, and some filtering | |||
Field, and some filtering engines might object to a message without a | engines might object to a message without a Subject, this policy is | |||
Subject, this policy is conservative and merely obscures that Header | conservative and merely obscures that Header Field by replacing it | |||
Field by replacing it with a fixed string [...]. By contrast, | with a fixed string [...]. By contrast, Comments and Keywords Header | |||
Comments and Keywords Header Fields are comparatively rare, so these | Fields are comparatively rare, so these fields are removed entirely | |||
fields are removed entirely from the Outer Header Section. | from the Outer Header Section. | |||
hcp_baseline(name, val_in) → val_out: | hcp_baseline(name, val_in) → val_out: | |||
if lower(name) is 'subject': | if lower(name) is 'subject': | |||
return '[...]' | return '[...]' | |||
else if lower(name) is in ['comments', 'keywords']: | else if lower(name) is in ['comments', 'keywords']: | |||
return null | return null | |||
else: | else: | |||
return val_in | return val_in | |||
hcp_baseline is the recommended default HCP for a new implementation, | hcp_baseline is the recommended default HCP for a new implementation, | |||
as it provides meaningful confidentiality protections and is unlikely | as it provides meaningful confidentiality protections and is unlikely | |||
to cause deliverability or usability problems. | to cause deliverability or usability problems. | |||
3.2.2. Shy Header Confidentiality Policy | 3.2.2. Shy Header Confidentiality Policy | |||
Alternately, a slightly more ambitious (and therefore more privacy- | Alternately, a slightly more ambitious (and therefore more privacy- | |||
preserving) Header Confidentiality Policy might avoid leaking human- | preserving) HCP might avoid leaking human-interpretable data that | |||
interpretable data that MTAs generally don't care about. The | MTAs generally don't care about. The additional protected data isn't | |||
additional protected data isn't related to message routing or | related to message routing or transport but might reveal sensitive | |||
transport but might reveal sensitive information about the sender or | information about the sender or their relationship to the recipients. | |||
their relationship to the recipients. This "shy" HCP builds on | This "shy" HCP builds on hcp_baseline but also: | |||
hcp_baseline but also: | ||||
* avoids revealing the display-name of each identified email address | * avoids revealing the display-name of each identified email address | |||
and | and | |||
* avoids leaking the sender's locally configured time zone in the | * avoids leaking the sender's locally configured time zone in the | |||
Date Header Field. | Date Header Field. | |||
hcp_shy(name, val_in) → val_out: | hcp_shy(name, val_in) → val_out: | |||
if lower(name) is 'from': | if lower(name) is 'from': | |||
if val_in is an RFC 5322 mailbox: | if val_in is an RFC 5322 mailbox: | |||
skipping to change at line 1114 ¶ | skipping to change at line 1112 ¶ | |||
to any Header Field: | to any Header Field: | |||
hcp_no_confidentiality(name, val_in) → val_out: | hcp_no_confidentiality(name, val_in) → val_out: | |||
return val_in | return val_in | |||
A conformant MUA that is not modified by local policy or | A conformant MUA that is not modified by local policy or | |||
configuration MUST NOT use hcp_no_confidentiality by default. | configuration MUST NOT use hcp_no_confidentiality by default. | |||
3.3. Default Header Confidentiality Policy | 3.3. Default Header Confidentiality Policy | |||
An MUA MUST have a default Header Confidentiality Policy that offers | An MUA MUST have a default HCP that offers confidentiality for the | |||
confidentiality for the Subject Header Field at least. Local policy | Subject Header Field at least. Local policy and configuration may | |||
and configuration may alter this default, but the MUA SHOULD NOT | alter this default, but the MUA SHOULD NOT require the user to select | |||
require the user to select an HCP. | an HCP. | |||
hcp_baseline provides confidentiality for the Subject Header Field by | hcp_baseline provides confidentiality for the Subject Header Field by | |||
replacing it with the literal string "[...]". It also provides | replacing it with the literal string "[...]". It also provides | |||
confidentiality for the other less common Informational Header Fields | confidentiality for the other less common Informational Header Fields | |||
(Comments and Keywords) by removing them entirely from the Outer | (Comments and Keywords) by removing them entirely from the Outer | |||
Header Section. This is a sensible default because most users treat | Header Section. This is a sensible default because most users treat | |||
the Informational Fields of a message (particularly the Subject) the | the Informational Fields of a message (particularly the Subject) the | |||
same way that they treat the Body, and they are surprised to find | same way that they treat the Body, and they are surprised to find | |||
that the Subject of an encrypted message is visible. | that the Subject of an encrypted message is visible. | |||
3.4. HCP Evolution | 3.4. HCP Evolution | |||
This document does not mandate any particular Header Confidentiality | This document does not mandate any particular HCP, though it offers | |||
Policy, though it offers guidance for MUA implementers in selecting | guidance for MUA implementers in selecting one in Section 3.3. | |||
one in Section 3.3. Future documents may recommend or mandate such a | Future documents may recommend or mandate such a policy for an MUA | |||
policy for an MUA with specific needs. Such a recommendation might | with specific needs. Such a recommendation might be motivated by | |||
be motivated by descriptions of metadata-derived attacks, stem from | descriptions of metadata-derived attacks, stem from research about | |||
research about message deliverability, or describe new signaling | message deliverability, or describe new signaling mechanisms, but | |||
mechanisms, but these topics are out of scope for this document. | these topics are out of scope for this document. | |||
3.4.1. Offering More Ambitious Header Confidentiality | 3.4.1. Offering More Ambitious Header Confidentiality | |||
An MUA MAY offer even more ambitious confidentiality for Header | An MUA MAY offer even more ambitious confidentiality for Header | |||
Fields of an encrypted message than defined in Section 3.2.2. For | Fields of an encrypted message than defined in Section 3.2.2. For | |||
example, it might implement an HCP that removes the To and Cc Header | example, it might implement an HCP that removes the To and Cc Header | |||
Fields entirely, relying on the SMTP envelope to ensure proper | Fields entirely, relying on the SMTP envelope to ensure proper | |||
routing. Or it might remove References and In-Reply-To so that | routing. Or it might remove References and In-Reply-To so that | |||
message threading is not visible to any MTA. Any more ambitious | message threading is not visible to any MTA. Any more ambitious | |||
choice might result in deliverability, rendering, or usability issues | choice might result in deliverability, rendering, or usability issues | |||
for the relevant messages, so testing and documentation will be | for the relevant messages, so testing and documentation will be | |||
valuable to get this right. | valuable to get this right. | |||
The authors of this document hope that implementers with deployment | The authors of this document hope that implementers with deployment | |||
experience will document their chosen Header Confidentiality Policy | experience will document their chosen HCP and the rationale behind | |||
and the rationale behind their choice. | their choice. | |||
3.4.2. Expert Guidance for Registering Header Confidentiality Policies | 3.4.2. Expert Guidance for Registering Header Confidentiality Policies | |||
There is no formal syntax specified for the Header Confidentiality | There is no formal syntax specified for the HCP, but any attempt to | |||
Policy, but any attempt to specify an HCP for inclusion in the | specify an HCP for inclusion in the registry needs to provide: | |||
registry needs to provide: | ||||
* a stable reference document clearly indicating the distinct name | * a stable reference document clearly indicating the distinct name | |||
for the proposed HCP, | for the proposed HCP, | |||
* pseudocode that other implementers can clearly and unambiguously | * pseudocode that other implementers can clearly and unambiguously | |||
interpret, | interpret, | |||
* a clear explanation of why this HCP is different from all other | * a clear explanation of why this HCP is different from all other | |||
registered HCPs, and | registered HCPs, and | |||
skipping to change at line 1230 ¶ | skipping to change at line 1227 ¶ | |||
* The MUA SHOULD include information in the message's Cryptographic | * The MUA SHOULD include information in the message's Cryptographic | |||
Summary to indicate the types of protection that applied to each | Summary to indicate the types of protection that applied to each | |||
rendered Header Field (if any). | rendered Header Field (if any). | |||
* If any Legacy Display Elements are present in the Body of the | * If any Legacy Display Elements are present in the Body of the | |||
message, it does not render them. | message, it does not render them. | |||
* When replying to a message with confidential Header Fields, the | * When replying to a message with confidential Header Fields, the | |||
replying MUA avoids leaking any Header Fields that were | replying MUA avoids leaking any Header Fields that were | |||
confidential in the original into the cleartext of the reply. It | confidential in the original into the cleartext of the reply. It | |||
does this even if its own Header Confidentiality Policy would not | does this even if its own HCP would not have treated those Header | |||
have treated those Header Fields as confidential. See Section 6 | Fields as confidential. See Section 6 for more details. | |||
for more details. | ||||
Note that an MUA that handles a message with Header Protection does | Note that an MUA that handles a message with Header Protection does | |||
_not_ need to render any new Header Fields that it did not render | _not_ need to render any new Header Fields that it did not render | |||
before. | before. | |||
4.1. Identifying That a Message Has Header Protection | 4.1. Identifying That a Message Has Header Protection | |||
An incoming message can be identified as having Header Protection | An incoming message can be identified as having Header Protection | |||
using the following test: | using the following test: | |||
skipping to change at line 2011 ¶ | skipping to change at line 2007 ¶ | |||
3. Return output. | 3. Return output. | |||
5.2. Composing a Message with Header Protection | 5.2. Composing a Message with Header Protection | |||
To compose a message using Header Protection, the composing MUA uses | To compose a message using Header Protection, the composing MUA uses | |||
the following inputs: | the following inputs: | |||
* all the inputs described in Section 5.1 | * all the inputs described in Section 5.1 | |||
* hcp: a Header Confidentiality Policy, as defined in Section 3 | * hcp: an HCP, as defined in Section 3 | |||
* respond: if the new message is a response to another message | * respond: if the new message is a response to another message | |||
(e.g., "Reply", "Reply All", "Forward", etc.), the MUA function | (e.g., "Reply", "Reply All", "Forward", etc.), the MUA function | |||
corresponding to the user's action (see Section 6.1), otherwise | corresponding to the user's action (see Section 6.1), otherwise | |||
null | null | |||
* refmsg: if the new message is a response to another message, the | * refmsg: if the new message is a response to another message, the | |||
message being responded to, otherwise null | message being responded to, otherwise null | |||
* legacy: a boolean value, indicating whether any recipient of the | * legacy: a boolean value, indicating whether any recipient of the | |||
skipping to change at line 2331 ¶ | skipping to change at line 2327 ¶ | |||
composing MUA SHOULD make use of the HP-Outer Header Fields from | composing MUA SHOULD make use of the HP-Outer Header Fields from | |||
within the Cryptographic Envelope of the reference message to ensure | within the Cryptographic Envelope of the reference message to ensure | |||
that Header Fields derived from the reference message do not leak in | that Header Fields derived from the reference message do not leak in | |||
the reply. | the reply. | |||
On a high level, this can be achieved as follows: Consider a Header | On a high level, this can be achieved as follows: Consider a Header | |||
Field in a reply message that is generated by derivation from a | Field in a reply message that is generated by derivation from a | |||
Header Field in the reference message. For example, the To Header | Header Field in the reference message. For example, the To Header | |||
Field is typically derived from the reference message's Reply-To or | Field is typically derived from the reference message's Reply-To or | |||
From Header Fields. When generating the outer copy of the Header | From Header Fields. When generating the outer copy of the Header | |||
Field, the composing MUA first applies its own Header Confidentiality | Field, the composing MUA first applies its own HCP. If the Header | |||
Policy. If the Header Field's value is changed by the HCP, then it | Field's value is changed by the HCP, then it is applied to the Outer | |||
is applied to the Outer Header Section. If the Header Field's value | Header Section. If the Header Field's value is unchanged, the | |||
is unchanged, the composing MUA re-generates the Header Field using | composing MUA re-generates the Header Field using the Header Fields | |||
the Header Fields that had been on the outside of the original | that had been on the outside of the original message at sending time. | |||
message at sending time. These can be inferred from the HP-Outer | These can be inferred from the HP-Outer Header Fields located within | |||
Header Fields located within the Cryptographic Payload of the | the Cryptographic Payload of the referenced message. If that value | |||
referenced message. If that value is itself different than the | is itself different than the protected value, then it is applied to | |||
protected value, then it is applied to the Outer Header Section. If | the Outer Header Section. If the value is the same as the protected | |||
the value is the same as the protected value, then it is simply | value, then it is simply copied to the Outer Header Section directly. | |||
copied to the Outer Header Section directly. Whether it was changed | Whether it was changed or not, it is noted in the protected Header | |||
or not, it is noted in the protected Header Section using HP-Outer, | Section using HP-Outer, as described in Section 2.2.1. | |||
as described in Section 2.2.1. | ||||
See Appendix D.2 for a simple worked example of this process. | See Appendix D.2 for a simple worked example of this process. | |||
Below we describe a supporting algorithm to handle this. It produces | Below we describe a supporting algorithm to handle this. It produces | |||
a list of Header Fields that should be obscured or removed in the new | a list of Header Fields that should be obscured or removed in the new | |||
message even if the sender's choice of Header Confidentiality Policy | message even if the sender's choice of HCP wouldn't normally remove | |||
wouldn't normally remove or obscure the Header Field in question. | or obscure the Header Field in question. This is effectively a | |||
This is effectively a single-use HCP. The normal sending guidance in | single-use HCP. The normal sending guidance in Section 5.2 applies | |||
Section 5.2 applies this single-use HCP to implement the high-level | this single-use HCP to implement the high-level guidance above. | |||
guidance above. | ||||
6.1.1. ReferenceHCP | 6.1.1. ReferenceHCP | |||
The algorithm takes two inputs: | The algorithm takes two inputs: | |||
* A single referenced message refmsg | * A single referenced message refmsg | |||
* A built-in MUA respond function associated with the user's action. | * A built-in MUA respond function associated with the user's action. | |||
The respond function takes a list of Header Fields from a | The respond function takes a list of Header Fields from a | |||
referenced message as input and generates a list of initial | referenced message as input and generates a list of initial | |||
candidate message Header Field names and values that are used to | candidate message Header Field names and values that are used to | |||
populate the message composition interface. Something like this | populate the message composition interface. Something like this | |||
function already exists in most MUAs, though it may differ across | function already exists in most MUAs, though it may differ across | |||
responsive actions. For example, the respond function that | responsive actions. For example, the respond function that | |||
implements "Reply All" is likely to be a different from the | implements "Reply All" is likely to be a different from the | |||
respond that implements "Reply". | respond that implements "Reply". | |||
As an output, it produces an ephemeral single-use Header | As an output, it produces an ephemeral single-use HCP, specific to | |||
Confidentiality Policy, specific to this kind of response to this | this kind of response to this specific message. | |||
specific message. | ||||
Method signature: | Method signature: | |||
ReferenceHCP(refmsg, respond) -> ephemeral_hcp | ReferenceHCP(refmsg, respond) -> ephemeral_hcp | |||
Procedure: | Procedure: | |||
1. If refmsg is not encrypted with Header Protection: | 1. If refmsg is not encrypted with Header Protection: | |||
i. Return hcp_no_confidentiality (there is no header | i. Return hcp_no_confidentiality (there is no header | |||
skipping to change at line 2569 ¶ | skipping to change at line 2562 ¶ | |||
Until that point, an end user might want to signal that their | Until that point, an end user might want to signal that their | |||
receiving MUAs are conformant to this document so that a peer | receiving MUAs are conformant to this document so that a peer | |||
composing a message to them can set legacy to false. A signal | composing a message to them can set legacy to false. A signal | |||
indicating capability of handling messages with Header Protection | indicating capability of handling messages with Header Protection | |||
might be placed in the user's cryptographic certificate or in | might be placed in the user's cryptographic certificate or in | |||
outbound messages. | outbound messages. | |||
This document does not attempt to define the syntax or semantics of | This document does not attempt to define the syntax or semantics of | |||
such a signal. | such a signal. | |||
8.2. More Ambitious Default Header Confidentiality Policy | 8.2. More Ambitious Default HCP | |||
This document defines a few different forms of Header Confidentiality | This document defines a few different forms of HCP. An MUA | |||
Policy. An MUA implementing an HCP for the first time SHOULD deploy | implementing an HCP for the first time SHOULD deploy hcp_baseline as | |||
hcp_baseline as recommended in Section 3.3. This HCP offers the most | recommended in Section 3.3. This HCP offers the most commonly | |||
commonly expected protection (obscuring the Subject Header Field) | expected protection (obscuring the Subject Header Field) without | |||
without risking deliverability or rendering issues. | risking deliverability or rendering issues. | |||
The HCPs proposed in this document are relatively conservative and | The HCPs proposed in this document are relatively conservative and | |||
still leak a significant amount of metadata for encrypted messages. | still leak a significant amount of metadata for encrypted messages. | |||
This is largely done to ensure deliverability (see Section 1.3.2) and | This is largely done to ensure deliverability (see Section 1.3.2) and | |||
usability, as messages without some critical Header Fields are more | usability, as messages without some critical Header Fields are more | |||
likely to not reach their intended recipient. | likely to not reach their intended recipient. | |||
In the future, some mail transport systems may accept and deliver | In the future, some mail transport systems may accept and deliver | |||
messages with even less publicly visible metadata. Many MTA | messages with even less publicly visible metadata. Many MTA | |||
operators today would ask for additional guarantees about such a | operators today would ask for additional guarantees about such a | |||
skipping to change at line 2697 ¶ | skipping to change at line 2690 ¶ | |||
* When rendering a message with a signed-and-encrypted or encrypted- | * When rendering a message with a signed-and-encrypted or encrypted- | |||
only cryptographic status with Header Protection but where the | only cryptographic status with Header Protection but where the | |||
Subject Header Field has not been removed or obscured, place a | Subject Header Field has not been removed or obscured, place a | |||
warning sign on the Subject line. | warning sign on the Subject line. | |||
Other simple rendering strategies could also be reasonable. | Other simple rendering strategies could also be reasonable. | |||
9.2. Users Should Not Have to Choose a Header Confidentiality Policy | 9.2. Users Should Not Have to Choose a Header Confidentiality Policy | |||
This document defines the abstraction of a Header Confidentiality | This document defines the abstraction of an HCP object for the sake | |||
Policy object for the sake of communication between implementers and | of communication between implementers and deployments. | |||
deployments. | ||||
Most email users are unlikely to understand the trade-offs between | Most email users are unlikely to understand the trade-offs between | |||
different policies. In particular, the potential negative side | different policies. In particular, the potential negative side | |||
effects (e.g., poor deliverability) may not be easily attributable by | effects (e.g., poor deliverability) may not be easily attributable by | |||
a normal user to a particular HCP. | a normal user to a particular HCP. | |||
Therefore, MUA implementers should be conservative in their choice of | Therefore, MUA implementers should be conservative in their choice of | |||
default HCP and should not require the Ordinary User to make an | default HCP and should not require the Ordinary User to make an | |||
incomprehensible choice that could cause unfixable, undiagnosable | incomprehensible choice that could cause unfixable, undiagnosable | |||
problems. The safest option is for the MUA developer to select a | problems. The safest option is for the MUA developer to select a | |||
skipping to change at line 3067 ¶ | skipping to change at line 3059 ¶ | |||
for more details about risks related to Bcc). | for more details about risks related to Bcc). | |||
Clearly, no end-to-end cryptographic protection of any Header Field | Clearly, no end-to-end cryptographic protection of any Header Field | |||
as defined in this document will hide such a sensitive field from the | as defined in this document will hide such a sensitive field from the | |||
intended recipient. Instead, the composing MUA MUST populate the | intended recipient. Instead, the composing MUA MUST populate the | |||
origheaders list for any outbound message with only information the | origheaders list for any outbound message with only information the | |||
recipient should have access to. This is true for messages without | recipient should have access to. This is true for messages without | |||
any cryptographic protection as well, of course, and it is even worse | any cryptographic protection as well, of course, and it is even worse | |||
there: Such a leak is exposed to the transport agents as well as the | there: Such a leak is exposed to the transport agents as well as the | |||
recipient. An encrypted message with Header Protection and a more | recipient. An encrypted message with Header Protection and a more | |||
ambitious Header Confidentiality Policy avoids these leaks that | ambitious HCP avoids these leaks that expose information to the | |||
expose information to the transport agents, but it cannot defend | transport agents, but it cannot defend against such a leak to the | |||
against such a leak to the recipient. | recipient. | |||
11.2.2. Encrypted Header Fields Can Be Inferred from External or | 11.2.2. Encrypted Header Fields Can Be Inferred from External or | |||
Internal Metadata | Internal Metadata | |||
For example, if the To and Cc Header Fields are removed from the | For example, if the To and Cc Header Fields are removed from the | |||
unprotected Header Section, the values in those fields might still be | unprotected Header Section, the values in those fields might still be | |||
inferred with high probability by an adversary who looks at the | inferred with high probability by an adversary who looks at the | |||
message either in transit or at rest. If the message is found in a | message either in transit or at rest. If the message is found in a | |||
mailbox, or being delivered to a mailbox, for example, | mailbox, or being delivered to a mailbox, for example, | |||
bob@example.org, it's likely that Bob was in either To or Cc. | bob@example.org, it's likely that Bob was in either To or Cc. | |||
skipping to change at line 4802 ¶ | skipping to change at line 4794 ¶ | |||
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA | iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA | |||
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ | MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ | |||
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli | sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli | |||
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== | vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== | |||
--508-- | --508-- | |||
C.2. Signed-Only Messages | C.2. Signed-Only Messages | |||
These messages are signed-only, using different schemes of Header | These messages are signed-only, using different schemes of Header | |||
Protection and different S/MIME structures. They use no Header | Protection and different S/MIME structures. They use no HCP because | |||
Confidentiality Policy because the HCP is only relevant when a | the HCP is only relevant when a message is encrypted. | |||
message is encrypted. | ||||
C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header | C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header | |||
Protection | Protection | |||
This is a signed-only S/MIME message via PKCS#7 signedData. The | This is a signed-only S/MIME message via PKCS#7 signedData. The | |||
payload is a text/plain message. It uses the Header Protection | payload is a text/plain message. It uses the Header Protection | |||
scheme from the draft. | scheme from the draft. | |||
It has the following structure: | It has the following structure: | |||
skipping to change at line 5717 ¶ | skipping to change at line 5708 ¶ | |||
These messages are signed and encrypted. They use PKCS#7 signedData | These messages are signed and encrypted. They use PKCS#7 signedData | |||
inside envelopedData, with different Header Protection schemes and | inside envelopedData, with different Header Protection schemes and | |||
different Header Confidentiality Policies. | different Header Confidentiality Policies. | |||
C.3.1. S/MIME Signed and Encrypted over a Simple Message, Header | C.3.1. S/MIME Signed and Encrypted over a Simple Message, Header | |||
Protection with hcp_baseline | Protection with hcp_baseline | |||
This is a signed-and-encrypted S/MIME message using PKCS#7 | This is a signed-and-encrypted S/MIME message using PKCS#7 | |||
envelopedData around signedData. The payload is a text/plain | envelopedData around signedData. The payload is a text/plain | |||
message. It uses the Header Protection scheme from the draft with | message. It uses the Header Protection scheme from the draft with | |||
the hcp_baseline Header Confidentiality Policy. | the hcp_baseline HCP. | |||
It has the following structure: | It has the following structure: | |||
└─╴application/pkcs7-mime [smime.p7m] 7825 bytes | └─╴application/pkcs7-mime [smime.p7m] 7825 bytes | |||
↧ (decrypts to) | ↧ (decrypts to) | |||
└─╴application/pkcs7-mime [smime.p7m] 4786 bytes | └─╴application/pkcs7-mime [smime.p7m] 4786 bytes | |||
⇩ (unwraps to) | ⇩ (unwraps to) | |||
└─╴text/plain 329 bytes | └─╴text/plain 329 bytes | |||
Its contents are: | Its contents are: | |||
skipping to change at line 12144 ¶ | skipping to change at line 12135 ¶ | |||
C H R | C H R | |||
C | C | |||
Compose Table 5 | Compose Table 5 | |||
ComposeNoHeaderProtection Table 5 | ComposeNoHeaderProtection Table 5 | |||
H | H | |||
HCP Section 1.7; Section 1.7; Section 3, Paragraph 2; | HCP Section 1.7; Section 1.7; Section 3, Paragraph 2; | |||
Section 3, Paragraph 5; Section 3.1, Paragraph 3; | Section 3, Paragraph 5; Section 3.1, Paragraph 1; | |||
Section 3.1, Paragraph 9; Section 3.1.1, Paragraph 1; | Section 3.1, Paragraph 3; Section 3.1, Paragraph 9; | |||
Section 3.2, Paragraph 2; Section 3.2, Paragraph 3; | Section 3.1.1, Paragraph 1; Section 3.2, Paragraph 2; | |||
Section 3.2, Paragraph 3; Section 3.2.1, Paragraph 1; | ||||
Section 3.2.1, Paragraph 3; Section 3.2.2, Paragraph 1; | Section 3.2.1, Paragraph 3; Section 3.2.2, Paragraph 1; | |||
Section 3.2.2, Paragraph 4; Section 3.3, Paragraph 1; | Section 3.2.2, Paragraph 4; Section 3.3, Paragraph 1; | |||
Section 3.4.1, Paragraph 1; Section 3.4.2, Paragraph 1; | Section 3.4, Paragraph 1; Section 3.4.1, Paragraph 1; | |||
Section 3.4.1, Paragraph 2; Section 3.4.2, Paragraph 1; | ||||
Section 3.4.2, Paragraph 2.1.1; Section 3.4.2, Paragraph | Section 3.4.2, Paragraph 2.1.1; Section 3.4.2, Paragraph | |||
2.3.1; Section 3.4.2, Paragraph 2.4.1; Section 3.4.2, | 2.3.1; Section 3.4.2, Paragraph 2.4.1; Section 3.4.2, | |||
Paragraph 3; Section 4.8.2, Paragraph 3; Section 5.2.1, | Paragraph 3; Section 4, Paragraph 5.4.1; Section 4.8.2, | |||
Paragraph 3; Section 5.2, Paragraph 2.2.1; Section 5.2.1, | ||||
Paragraph 4.5.2.2.2.1.1; Section 6.1, Paragraph 5; | Paragraph 4.5.2.2.2.1.1; Section 6.1, Paragraph 5; | |||
Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 7.8.1; | Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 3; | |||
Section 6.1.1, Paragraph 8; Section 8.2, Paragraph 1; | Section 6.1.1, Paragraph 7.8.1; Section 6.1.1, Paragraph 8; | |||
Section 8.2, Paragraph 4; Section 8.2, Paragraph 5; | Section 8.2, Paragraph 1; Section 8.2, Paragraph 4; | |||
Section 8.2, Paragraph 6; Section 9.2, Paragraph 2; | Section 8.2, Paragraph 5; Section 8.2, Paragraph 6; | |||
Section 9.2, Paragraph 1; Section 9.2, Paragraph 2; | ||||
Section 9.2, Paragraph 3; Section 11.2, Paragraph 1; | Section 9.2, Paragraph 3; Section 11.2, Paragraph 1; | |||
Section 11.2.1, Paragraph 1; Section 11.2.3, Paragraph 1; | Section 11.2.1, Paragraph 1; Section 11.2.1, Paragraph 3; | |||
Section 11.2.3, Paragraph 2; Section 11.3, Paragraph 2; | Section 11.2.3, Paragraph 1; Section 11.2.3, Paragraph 2; | |||
Section 11.4, Paragraph 2; Section 12, Paragraph 1; Table 5; | Section 11.3, Paragraph 2; Section 11.4, Paragraph 2; | |||
Appendix D.1.2, Paragraph 1; Appendix D.2.2, Paragraph 3; | Section 12, Paragraph 1; Table 5; Appendix C.2, Paragraph 1; | |||
Appendix D.2.2, Paragraph 6 | Appendix C.3.1, Paragraph 1; Appendix D.1.2, Paragraph 1; | |||
Appendix D.2.2, Paragraph 3; Appendix D.2.2, Paragraph 6 | ||||
Header Confidentiality Policy Section 1.2, Paragraph 4; | Header Confidentiality Policy Section 1.2, Paragraph 4; | |||
Section 1.7; Section 3, Paragraph 2; Section 3.1, Paragraph | Section 1.7; Section 3, Paragraph 2; Section 12.3; | |||
1; Section 3.2.1, Paragraph 1; Section 3.2.2, Paragraph 1; | Appendix C.3.2, Paragraph 1; Appendix C.3.3, Paragraph 1; | |||
Section 3.3, Paragraph 1; Section 3.4, Paragraph 1; | Appendix C.3.4, Paragraph 1; Appendix C.3.5, Paragraph 1; | |||
Section 3.4.1, Paragraph 2; Section 3.4.2, Paragraph 1; | Appendix C.3.6, Paragraph 1; Appendix C.3.7, Paragraph 1; | |||
Section 4, Paragraph 5.4.1; Section 5.2, Paragraph 2.2.1; | Appendix C.3.8, Paragraph 1; Appendix C.3.9, Paragraph 1; | |||
Section 6.1, Paragraph 5; Section 6.1, Paragraph 7; | Appendix C.3.10, Paragraph 1; Appendix C.3.11, Paragraph 1; | |||
Section 6.1.1, Paragraph 3; Section 8.2, Paragraph 1; | Appendix C.3.12, Paragraph 1; Appendix C.3.13, Paragraph 1; | |||
Section 9.2, Paragraph 1; Section 11.2.1, Paragraph 3; | Appendix C.3.14, Paragraph 1; Appendix C.3.15, Paragraph 1; | |||
Section 12.3; Appendix C.2, Paragraph 1; Appendix C.3.1, | Appendix C.3.16, Paragraph 1; Appendix C.3.17, Paragraph 1 | |||
Paragraph 1; Appendix C.3.2, Paragraph 1; Appendix C.3.3, | ||||
Paragraph 1; Appendix C.3.4, Paragraph 1; Appendix C.3.5, | ||||
Paragraph 1; Appendix C.3.6, Paragraph 1; Appendix C.3.7, | ||||
Paragraph 1; Appendix C.3.8, Paragraph 1; Appendix C.3.9, | ||||
Paragraph 1; Appendix C.3.10, Paragraph 1; Appendix C.3.11, | ||||
Paragraph 1; Appendix C.3.12, Paragraph 1; Appendix C.3.13, | ||||
Paragraph 1; Appendix C.3.14, Paragraph 1; Appendix C.3.15, | ||||
Paragraph 1; Appendix C.3.16, Paragraph 1; Appendix C.3.17, | ||||
Paragraph 1 | ||||
HeaderFieldProtection Section 4.10.2, Paragraph 2.2.1; Table 5 | HeaderFieldProtection Section 4.10.2, Paragraph 2.2.1; Table 5 | |||
HeaderSetsFromMessage Section 4.3.1, Paragraph 4.2.1; | HeaderSetsFromMessage Section 4.3.1, Paragraph 4.2.1; | |||
Section 4.10.2, Paragraph 2.2.1; Section 4.10.2, Paragraph | Section 4.10.2, Paragraph 2.2.1; Section 4.10.2, Paragraph | |||
2.4.1; Table 5 | 2.4.1; Table 5 | |||
R | R | |||
ReferenceHCP Table 5 | ReferenceHCP Table 5 | |||
RFC8551HP Section 1.1, Paragraph 1; Section 1.1, Paragraph 2; | RFC8551HP Section 1.1, Paragraph 1; Section 1.1, Paragraph 2; | |||
Section 1.1.1, Paragraph 1; Section 1.1.1, Paragraph 2; | Section 1.1.1, Paragraph 1; Section 1.1.1, Paragraph 2; | |||
End of changes. 26 change blocks. | ||||
110 lines changed or deleted | 97 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |