Thanks Barry I sent a pull request along to Scott with the changes.
I also generated an rfcdiff which I include for completeness sake. thanks tim On Sun, Feb 28, 2021 at 5:02 PM Barry Leiba <barryle...@computer.org> wrote: > It looks right to me. Thanks, Tim. > > Barry > > On Sun, Feb 28, 2021 at 4:53 PM Tim Wicinski <tjw.i...@gmail.com> wrote: > >> I was just working on merging Barry's comments with Dave's and Kurt's. >> >> I attached what should be correct. I would like someone to just double >> check my work. >> >> tim >> >> >> On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy <superu...@gmail.com> >> wrote: >> >>> These all work for me. Thanks for the contributions. >>> >>> Scott, please work your magic with a revision so the chairs can request >>> publication and we can get this on its way. >>> >>> -MSK >>> >>> On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker <dcroc...@gmail.com> wrote: >>> >>>> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote: >>>> >>>> Especially in the case of the PSD policies, one should not expect that >>>> the controlling organization would necessarily be "a mail-originating >>>> organization". Generally the idea is to *disavow* being such :-) >>>> >>>> Suggested alternate text: >>>> >>>> Domain-based Message Authentication, Reporting, and Conformance (DMARC) >>>> permits a domain-controlling >>>> organization to express domain-level policies and preferences for >>>> message validation, disposition, and reporting, >>>> which a mail-receiving organization can use to improve mail handling. >>>> >>>> +1 >>>> >>>> d/ >>>> >>>> -- >>>> Dave crockerdcroc...@gmail.com >>>> 408.329.0791 >>>> >>>> Volunteer, Silicon Valley Chapter >>>> American Red crossdave.crock...@redcross.org >>>> >>>> _______________________________________________ >>>> dmarc mailing list >>>> dmarc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmarc >>>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>Title: Diff: draft-ietf-dmarc-psd-11.txt - draft-ietf-dmarc-psd-10.txt
draft-ietf-dmarc-psd-11.txt | draft-ietf-dmarc-psd-10.txt | |||
---|---|---|---|---|
Network Working Group S. Kitterman | Network Working Group S. Kitterman | |||
Internet-Draft fTLD Registry Services | Internet-Draft fTLD Registry Services | |||
Intended status: Experimental January 1, 2021 | Intended status: Experimental January 23, 2021 | |||
Expires: July 5, 2021 | Expires: July 27, 2021 | |||
Experimental DMARC Extension For Public Suffix Domains | Experimental DMARC Extension For Public Suffix Domains | |||
draft-ietf-dmarc-psd-11 | draft-ietf-dmarc-psd-10 | |||
Abstract | Abstract | |||
Domain-based Message Authentication, Reporting, and Conformance | DMARC (Domain-based Message Authentication, Reporting, and | |||
(DMARC) permits a domain-controlling organization to express domain- | Conformance) is a scalable mechanism by which a mail-originating | |||
level policies and preferences for message validation, disposition, | organization can express domain-level policies and preferences for | |||
and reporting, which a mail-receiving organization can use to improve | message validation, disposition, and reporting, that a mail-receiving | |||
mail handling. | organization can use to improve mail handling. The design of DMARC | |||
presumes that domain names represent either nodes in the tree below | ||||
which registrations occur, or nodes where registrations have | ||||
occurred; it does not permit a domain name to have both of these | ||||
properties simultaneously. Since its deployment in 2015, use of | ||||
DMARC has shown a clear need for the ability to express policy for | ||||
these domains as well. | ||||
DMARC distinguishes the portion of a name that is a Public Suffix | Domains at which registrations can occur are referred to as Public | |||
Domain (PSD), below which organizational domain names are created. | Suffix Domains (PSDs). This document describes an extension to DMARC | |||
The basic DMARC capability allows organizational domains to specify | to enable DMARC functionality for PSDs. | |||
policies that apply to their subdomains, but it does not give that | ||||
capability to PSDs. This document describes an extension to DMARC to | ||||
fully enable DMARC functionality for PSDs. | ||||
Some implementations of DMARC consider a PSD to be ineligible for | This document also seeks to address implementations that consider a | |||
DMARC enforcement. This specification addresses that case. | domain on a public Suffix list to be ineligible for DMARC | |||
enforcement. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on July 5, 2021. | This Internet-Draft will expire on July 27, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 34 | skipping to change at page 2, line 34 | |||
1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 | |||
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 | 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 | |||
2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5 | 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5 | |||
2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 6 | 2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 6 | |||
2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.5. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 6 | 2.5. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 6 | |||
2.6. PSO Controlled Domain Names . . . . . . . . . . . . . . . 6 | 2.6. PSO Controlled Domain Names . . . . . . . . . . . . . . . 6 | |||
2.7. Non-existent Domains . . . . . . . . . . . . . . . . . . 6 | 2.7. Non-existent Domains . . . . . . . . . . . . . . . . . . 6 | |||
3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6 | 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6 | |||
3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6 | 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Changes in Section 6.3 "General Record Format" . . . . . 7 | 3.2. Changes in Section 6.3 "General Record Format" . . . . . 7 | |||
3.3. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 7 | 3.3. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 7 | |||
3.4. Changes in Section 6.6.1 "Extract Author Domain" . . . . 7 | 3.4. Changes in Section 6.6.1 "Extract Author Domain" . . . . 7 | |||
3.5. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 8 | 3.5. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 8 | |||
3.6. Changes in Section 7 "DMARC Feedback" . . . . . . . . . . 8 | 3.6. Changes in Section 7 "DMARC Feedback" . . . . . . . . . . 8 | |||
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 | 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8 | 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 9 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 10 | 6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 10 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 11 | 7.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12 | Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12 | |||
Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12 | Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12 | |||
B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12 | B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12 | |||
B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12 | B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12 | |||
B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13 | B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13 | |||
Appendix C. Implementations . . . . . . . . . . . . . . . . . . 13 | Appendix C. Implementations . . . . . . . . . . . . . . . . . . 13 | |||
C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13 | C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13 | |||
C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14 | C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
1. Introduction | 1. Introduction | |||
DMARC ([RFC7489]) provides a mechanism for publishing organizational | DMARC [RFC7489] provides a mechanism for publishing organizational | |||
policy information to email receivers. DMARC allows policy to be | policy information to email receivers. DMARC allows policy to be | |||
specified for both individual domains and for organizational domains | specified for both individual domains and for organizational domains | |||
and their sub-domains within a single organization. | and their sub-domains within a single organization. | |||
To determine the organizational domain for a message under | To determine the organizational domain for a message under | |||
evaluation, and thus where to look for a policy statement, DMARC | evaluation, and thus where to look for a policy statement, DMARC | |||
makes use of a Public Suffix List. The process for doing this can be | makes use of a Public Suffix List. The process for doing this can be | |||
found in Section 3.2 of the DMARC specification. | found in Section 3.2 of the DMARC specification. | |||
In the basic DMARC model, PSDs are not organizational domains and are | DMARC as specified presumes that domain names present in a PSL are | |||
thus not subject to DMARC processing. In DMARC, domains fall into | not organizational domains and thus not subject to DMARC processing; | |||
one of three categories: organizational domains, sub-domains of | domains are either organizational domains, sub-domains of | |||
organizational domains, or PSDs. A PSD can only publish DMARC policy | organizational domains, or listed on a PSL. For domains listed in a | |||
for itself, and not for any sub-domains under it. In some cases, | PSL, i.e., TLDs and domains that exist between TLDs and organization | |||
this limitation allows for the abuse of non-existent organizational- | level domains, policy can only be published for the exact domain. No | |||
level domains and hampers identification of domain abuse in email. | method is available for these domains to express policy or receive | |||
feedback reporting for sub-domains. This missing method allows for | ||||
the abuse of non-existent organizational-level domains and prevents | ||||
identification of domain abuse in email. | ||||
This document specifies experimental updates to the DMARC and PSL | This document specifies experimental updates to the DMARC and PSL | |||
algorithm cited above, in an attempt to mitigate this abuse. | algorithm cited above, in an attempt to mitigate this abuse. | |||
1.1. Example | 1.1. Example | |||
As an example, imagine a Top-Level Domain (TLD), ".example", that has | As an example, imagine a country code TLD (ccTLD) which has public | |||
public subdomains for government and commercial use (".gov.example" | subdomains for government and commercial use (".gov.example" and | |||
and ".com.example"). The maintainer of a list of such a PSD | ".com.example"). A PSL whose maintainer is aware of this country's | |||
structure would include entries for both of these sub-domains, | domain structurewould include entries for both of these in the PSL, | |||
thereby indicating that they are PSDs, below which organizational | indicating that they are PSDs below which registrations can occur. | |||
domains can be registered. Suppose further that there exists a | Suppose further that there exists a domain "tax.gov.example", | |||
legitimate domain called "tax.gov.example", registered within | registered within ".gov.example", that is responsible for taxation in | |||
".gov.example". | this imagined country. | |||
However, by exploiting the typically unauthenticated nature of email, | However, by exploiting the typically unauthenticated nature of email, | |||
there are regular malicious campaigns to impersonate this | there are regular malicious campaigns to impersonate this | |||
organization that use similar-looking ("cousin") domains such as | organization that use similar-looking ("cousin") domains such as | |||
"t4x.gov.example". Such domains are not registered. | "t4x.gov.example". Such domains are not registered. | |||
Within the ".gov.example" public suffix, use of DMARC has been | Within the ".gov.example" public suffix, use of DMARC has been | |||
mandated, so "gov.example" publishes the following DMARC DNS record: | mandated, so "gov.example" publishes the following DMARC DNS record: | |||
_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; " | _dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; " | |||
"rua=mailto:d...@dmarc.svc.gov.example" ) | "rua=mailto:d...@dmarc.svc.gov.example" ) | |||
This DMARC record provides policy and a reporting destination for | This DMARC record provides policy and a reporting destination for | |||
mail sent from @gov.example. Similarly, "tax.gov.example" will have | mail sent from @gov.example. However, due to DMARC's current method | |||
a DMARC record that specifies policy for mail sent from addresses | of discovering and applying policy at the organizational domain | |||
@tax.gov.example. However, due to DMARC's current method of | level, the non-existent organizational domain of @t4x.gov.example | |||
discovering and applying policy at the organizational domain level, | does not and cannot fall under a DMARC policy. | |||
the non-existent organizational domain of @t4x.gov.example does not | ||||
and cannot fall under a DMARC policy. | ||||
Defensively registering all variants of "tax" is obviously not a | Defensively registering all variants of "tax" is obviously not a | |||
scalable strategy. The intent of this specification, therefore, is | scalable strategy. The intent of this specification, therefore, is | |||
to enhance the DMARC algorithm by enabling an agent receiving such a | to enhance the DMARC algorithm by enabling an agent receiving such a | |||
message to be able to determine that a relevant policy is present at | message to be able to determine that a relevant policy is present at | |||
"gov.example", which is precluded by the current DMARC algorithm. | "gov.example", which is precluded by the current DMARC algorithm. | |||
1.2. Discussion | 1.2. Discussion | |||
This document provides a simple extension to [RFC7489] to allow | This document provides a simple extension to DMARC [RFC7489] to allow | |||
operators of Public Suffix Domains (PSDs) to: | operators of Public Suffix Domains (PSDs) to: | |||
o Express policy at the level of the PSD that covers all | o Express policy at the level of the PSD that covers all | |||
organizational domains that do not explicitly publish DMARC | organizational domains that do not explicitly publish DMARC | |||
records | records | |||
o Extends the DMARC policy query functionality to detect and process | o Extends the DMARC policy query functionality to detect and process | |||
such a policy | such a policy | |||
o Describes receiver feedback for such policies | o Describes receiver feedback for such policies | |||
skipping to change at page 4, line 48 | skipping to change at page 4, line 49 | |||
This document also provides a new DMARC tag to indicate requested | This document also provides a new DMARC tag to indicate requested | |||
handling policy for non-existent subdommains. This is provided | handling policy for non-existent subdommains. This is provided | |||
specifically to support phased deployment of PSD DMARC, but is | specifically to support phased deployment of PSD DMARC, but is | |||
expected to be useful more generally. Undesired rejection risks for | expected to be useful more generally. Undesired rejection risks for | |||
mail purporting to be from domains that do not exist are | mail purporting to be from domains that do not exist are | |||
substantially lower than for those that do, so the operational risk | substantially lower than for those that do, so the operational risk | |||
of requesting harsh policy treatment (e.g. reject) is lower. | of requesting harsh policy treatment (e.g. reject) is lower. | |||
As an additional benefit, the PSD DMARC extension clarifies existing | As an additional benefit, the PSD DMARC extension clarifies existing | |||
requirements. Based on the requirements of [RFC7489], DMARC should | requirements. Based on the requirements of DMARC [RFC7489], DMARC | |||
function above the organizational level for exact domain matches | should function above the organizational level for exact domain | |||
(i.e. if a DMARC record were published for 'example', then mail from | matches (i.e. if a DMARC record were published for 'example', then | |||
example@example should be subject to DMARC processing). Testing had | mail from example@example should be subject to DMARC processing). | |||
revealed that this is not consistently applied in different | ||||
implementations. | Testing had revealed that this is not consistently applied in | |||
different implementations. | ||||
There are two types of Public Suffix Operators (PSOs) for which this | There are two types of Public Suffix Operators (PSOs) for which this | |||
extension would be useful and appropriate: | extension would be useful and appropriate: | |||
o Branded PSDs (e.g., ".google"): These domains are effectively | o Branded PSDs (e.g., ".google"): These domains are effectively | |||
Organizational Domains as discussed in [RFC7489]. They control | Organizational Domains as discussed in DMARC [RFC7489]. They | |||
all subdomains of the tree. These are effectively private | control all subdomains of the tree. These are effectively private | |||
domains, but listed in the Public Suffix List. They are treated | domains, but listed in the Public Suffix List. They are treated | |||
as Public for DMARC purposes. They require the same protections | as Public for DMARC purposes. They require the same protections | |||
as DMARC Organizational Domains, but are currently unable to | as DMARC Organizational Domains, but are currently unable to | |||
benefit from DMARC. | benefit from DMARC. | |||
o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): | o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): | |||
Because existing Organizational Domains using this PSD have their | Because existing Organizational Domains using this PSD have their | |||
own DMARC policy, the applicability of this extension is for non- | own DMARC policy, the applicability of this extension is for non- | |||
existent domains. The extension allows the brand protection | existent domains. The extension allows the brand protection | |||
benefits of DMARC to extend to the entire PSD, including cousin | benefits of DMARC to extend to the entire PSD, including cousin | |||
domains of registered organizations. | domains of registered organizations. | |||
Due to the design of DMARC and the nature of the Internet email | Due to the design of DMARC and the nature of the Internet email | |||
architecture [RFC5598], there are interoperability issues associated | architecture [RFC5598], there are interoperability issues associated | |||
with DMARC deployment. These are discussed in Interoperability | with DMARC [RFC7489] deployment. These are discussed in | |||
Issues between DMARC and Indirect Email Flows [RFC7960]. These | Interoperability Issues between DMARC and Indirect Email Flows | |||
issues are not typically applicable to PSDs, since they (e.g., the | [RFC7960]. These issues are not typically applicable to PSDs, since | |||
".gov.example" used above) do not typically send mail. | they (e.g., the ".gov.example" used above) do not typically send | |||
mail. | ||||
2. Terminology and Definitions | 2. Terminology and Definitions | |||
This section defines terms used in the rest of the document. | This section defines terms used in the rest of the document. | |||
2.1. Conventions Used in This Document | 2.1. Conventions Used in This Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
skipping to change at page 6, line 16 | skipping to change at page 6, line 17 | |||
tree at which to register domain names "owned" by independent | tree at which to register domain names "owned" by independent | |||
organizations. Real-world examples are ".com", ".org", ".us", and | organizations. Real-world examples are ".com", ".org", ".us", and | |||
".gov.uk". Names at which such registrations occur are called Public | ".gov.uk". Names at which such registrations occur are called Public | |||
Suffix Domains (PSDs), and a registration consists of a label | Suffix Domains (PSDs), and a registration consists of a label | |||
selected by the registrant to which a desirable PSD is appended. For | selected by the registrant to which a desirable PSD is appended. For | |||
example, "ietf.org" is a registered domain name, and ".org" is its | example, "ietf.org" is a registered domain name, and ".org" is its | |||
PSD. | PSD. | |||
2.3. Organizational Domain | 2.3. Organizational Domain | |||
The term Organizational Domains is defined in [RFC7489] Section 3.2. | The term Organizational Domains is defined in DMARC [RFC7489] | |||
Section 3.2. | ||||
2.4. Longest PSD | 2.4. Longest PSD | |||
The longest PSD is the Organizational Domain with one label removed. | The longest PSD is the Organizational Domain with one label removed. | |||
It names the immediate parent node of the Organizational Domain in | It names the immediate parent node of the Organizational Domain in | |||
the DNS namespace tree. | the DNS namespace tree. | |||
2.5. Public Suffix Operator (PSO) | 2.5. Public Suffix Operator (PSO) | |||
A Public Suffix Operator is an organization which manages operations | A Public Suffix Operator is an organization which manages operations | |||
skipping to change at page 11, line 46 | skipping to change at page 11, line 46 | |||
DOI 10.17487/RFC6973, July 2013, | DOI 10.17487/RFC6973, July 2013, | |||
<https://www.rfc-editor.org/info/rfc6973>. | <https://www.rfc-editor.org/info/rfc6973>. | |||
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., | [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., | |||
Trammell, B., Huitema, C., and D. Borkmann, | Trammell, B., Huitema, C., and D. Borkmann, | |||
"Confidentiality in the Face of Pervasive Surveillance: A | "Confidentiality in the Face of Pervasive Surveillance: A | |||
Threat Model and Problem Statement", RFC 7624, | Threat Model and Problem Statement", RFC 7624, | |||
DOI 10.17487/RFC7624, August 2015, | DOI 10.17487/RFC7624, August 2015, | |||
<https://www.rfc-editor.org/info/rfc7624>. | <https://www.rfc-editor.org/info/rfc7624>. | |||
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky, | [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, | |||
E., Ed., and K. Andersen, Ed., "Interoperability Issues | E., Ed., and K. Andersen, Ed., "Interoperability Issues | |||
between Domain-based Message Authentication, Reporting, | between Domain-based Message Authentication, Reporting, | |||
and Conformance (DMARC) and Indirect Email Flows", | and Conformance (DMARC) and Indirect Email Flows", | |||
RFC 7960, DOI 10.17487/RFC7960, September 2016, | RFC 7960, DOI 10.17487/RFC7960, September 2016, | |||
<https://www.rfc-editor.org/info/rfc7960>. | <https://www.rfc-editor.org/info/rfc7960>. | |||
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is | [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is | |||
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, | Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, | |||
November 2016, <https://www.rfc-editor.org/info/rfc8020>. | November 2016, <https://www.rfc-editor.org/info/rfc8020>. | |||
End of changes. 18 change blocks. | ||||
56 lines changed or deleted | 64 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc