-
Notifications
You must be signed in to change notification settings - Fork 4
/
draft-ietf-dmarc-psd-01.txt
504 lines (312 loc) · 18.4 KB
/
draft-ietf-dmarc-psd-01.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
Network Working Group S. Kitterman
Internet-Draft fTLD Registry Services
Updates: 7489 (if approved) January 14, 2019
Intended status: Informational
Expires: July 18, 2019
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Extension For PSDs (Public Suffix Domains)
draft-ietf-dmarc-psd-01
Abstract
DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling. DMARC policies can be
applied at the individual domain level or for a set of domains at the
organizational level. The design of DMARC precludes grouping
policies for a set of domains above the organizational level, such as
TLDs (Top Level Domains). These types of domains (which are not all
at the top level of the DNS tree) can be collectively referred to as
Public Suffix Domains (PSDs). For the subset of PSDs that require
DMARC usage, this memo describes an extension to DMARC to enable
DMARC functionality for such domains.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 18, 2019.
Kitterman Expires July 18, 2019 [Page 1]
Internet-Draft PSD DMARC January 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 4
2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 4
2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5
2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5
3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 5
3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 5
3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 5
3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 5
3.4. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 5
3.5. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 6
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
DMARC [RFC7489] provides a mechanism for publishing organizational
policy information to email receivers. DMARC [RFC7489] allows policy
to be specified for both individual domains and sets of domains
within a single organization. For domains above the organizational
level in the DNS tree, policy can only be published for the exact
Kitterman Expires July 18, 2019 [Page 2]
Internet-Draft PSD DMARC January 2019
domain. There is no method available to such domains to express
lower level policy or receive feedback reporting for sets of domains.
This prevents policy application to non-existent domains and
identification of domain abuse in email, which can be important for
brand and consumer protection.
As an example, imagine a country code TLD (ccTLD) which has public
subdomains for government and commercial use (.gov.example and
.com.example). Within the .gov.example public suffix, use of DMARC
[RFC7489] has been mandated and .gov.example has published its own
DMARC [RFC7489] record:
"v=DMARC1;p=reject;rua=mailto:[email protected]"
at
_dmarc.gov.example.
This would provide policy and feedback for mail sent from
@gov.example, but not @tax.gov.example and there is no way to publish
an organizational level policy that would do so. While, in theory,
receivers could reject mail from non-existent domains, not all
receivers do so. Non-existence of the sending domain can be a factor
in a mail delivery decision, but is not generally treated as
definitive on its own.
This memo provides a simple extension to DMARC [RFC7489] to allow
operators of Public Suffix Domains (PSDs) to express policy for
groups of subdomains, extends the DMARC [RFC7489] policy query
functionality to detect and process such a policy, describes receiver
feedback for such policies, and provides controls to mitigate
potential privacy considerations associated with this extension.
There are two types of Public Suffix Operators (PSOs) for which this
extension would be useful and appropriate:
o Branded PSDs (e.g., ".google"): These domains are effectively
Organizational Domains as discussed in DMARC [RFC7489]. They
control all subdomains of the tree. These are effectively private
domains, but listed in the Public Suffix List. They are treated
as Public for DMARC [RFC7489] purposes. They require the same
protections as DMARC [RFC7489] Organizational Domains, but are
currently excluded.
o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
Because existing Organizational Domains using this PSD have their
own DMARC policy, the applicability of this extension is for non-
existent domains. The extension allows the brand protection
Kitterman Expires July 18, 2019 [Page 3]
Internet-Draft PSD DMARC January 2019
benefits of DMARC [RFC7489] to extend to the entire PSD, including
cousin domains of registered organizations.
Due to the design of DMARC [RFC7489] and the nature of the Internet
email architecture [RFC5598], there are interoperability issues
associated with DMARC [RFC7489] deployment. These are discussed in
Interoperability Issues between DMARC and Indirect Email Flows
[RFC7960]. These issues are not applicable to PSDs, since they
(e.g., the ".gov.example" used above) do not send mail.
DMARC [RFC7489], by design, does not support usage by PSOs. For PSDs
that require use of DMARC [RFC7489], an extension of DMARC reporting
and enforcement capability is needed for PSO to effectively manage
and monitor implementation of PSD requirements.
2. Terminology and Definitions
This section defines terms used in the rest of the document.
2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Public Suffix Domain (PSD)
The global Internet Domain Name System (DNS) is documented in
numerous Requests for Comment (RFC). It defines a tree of names
starting with root, ".", immediately below which are Top Level Domain
names such as ".com" and ".us". They are not available for private
registration. In many cases the public portion of the DNS tree is
more than one level deep. PSD DMARC includes all public domains
above the organizational level in the tree, e.g., ".gov.uk".
2.3. Longest PSD
Organizational Domain (DMARC [RFC7489] Section 3.2) with one label
removed.
2.4. Public Suffix Operator (PSO)
A Public Suffix Operator manages operations within their PSD.
Kitterman Expires July 18, 2019 [Page 4]
Internet-Draft PSD DMARC January 2019
2.5. PSO Controlled Domain Names
PSO Controlled Domain Names are names in the DNS that are managed by
a PSO and are not available for use as Organizational Domains (the
term Organizational Domains is defined in DMARC [RFC7489]
Section 3.2). Depending on PSD policy, these will have one (e.g.,
".com") or more (e.g., ".co.uk") name components.
2.6. Non-existent Domains
For DMARC [RFC7489] purposes, a non-existent domain is a domain name
that publishes none of A, AAAA, or MX records that the receiver is
willing to accept. This is a broader definition than that in
NXDOMAIN [RFC8020].
3. PSD DMARC Updates to DMARC Requirements
This document updates DMARC [RFC7489] as follows:
3.1. General Updates
References to "Domain Owners" also apply to PSOs.
3.2. Section 6.1 DMARC Policy Record
PSD DMARC records are published as a subdomain of the PSD. For the
PSD ".example", the PSO would post DMARC policy in a TXT record at
"_dmarc.example".
3.3. Section 6.5. Domain Owner Actions
In addition to the DMARC [RFC7489] domain owner actions, PSOs that
require use of DMARC ought to make that information available to
receivers.
3.4. Section 6.6.3. Policy Discovery
A new step between step 3 and 4 is added:
3A. If the set is now empty and the longest PSD (Section 2.3) of the
Organizational Domain is one that the receiver has determined is
acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for
a DMARC TXT record at the DNS domain matching the longest PSD
(Section 2.3) in place of the RFC5322.From domain in the message
(if different). A possibly empty set of records is returned.
As an example, for a message with the Organizational Domain of
"example.compute.cloudcompany.com.cctld", the query for PSD DMARC
Kitterman Expires July 18, 2019 [Page 5]
Internet-Draft PSD DMARC January 2019
would use "compute.cloudcompany.com.cctld" as the longest PSD
(Section 2.3). The receiver would check to see if that PSD is listed
in the DMARC PSD Registry, and if so, perform the policy lookup at
"_dmarc.compute.cloudcompany.com.cctld".
Note: Because the PSD policy query comes after the Organizational
Domain policy query, PSD policy is not used for Organizational
domains that have published a DMARC [RFC7489] policy. Specifically,
this is not a mechanism to provide feedback addresses (RUA/RUF) when
an Organizational Domain has declined to do so.
3.5. Section 7. DMARC Feedback
Operational note for PSD DMARC: For PSOs, feedback for non-existent
domains is desired and useful. See Section 4 for discussion of
Privacy Considerations.
4. Privacy Considerations
These privacy considerations are developed based on the requiremetns
of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this
document.
4.1. Feedback leakage
Providing feedback reporting to PSOs can, in some cases, create
leakage of information outside of an organization to the PSO. This
leakage could be potentially be utilized as part of a program of
pervasive surveillance (See [RFC7624]). There are roughly three
cases to consider:
o Single Organization PSDs (e.g., ".google"), RUA and RUF reports
based on PSD DMARC have the potential to contain information about
emails related to entities managed by the organization. Since
both the PSO and the Organizational Domain owners are common,
there is no additional privacy risk for either normal or non-
existent Domain reporting due to PSD DMARC.
o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
PSD DMARC based reports will only be generated for domains that do
not publish a DMARC policy at the organizational or host level.
For domains that do publish the required DMARC policy records, the
feedback reporting addresses (RUA and RUF) of the organization (or
hosts) will be used. The only direct feedback leakage risk for
these PSDs are for Organizational Domains that are out of
compliance with PSD policy. Data on non-existent cousin domains
would be sent to the PSO.
Kitterman Expires July 18, 2019 [Page 6]
Internet-Draft PSD DMARC January 2019
o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
usage. Privacy risks for Organizational Domains that have not
deployed DMARC within such PSDs are significant. For non-DMARC
Organizational Domains, all DMARC feedback will be directed to the
PSO. PSD DMARC is opt-out (by publishing a DMARC record at the
Organizational Domain level) vice opt-in, which would be the more
desirable characteristic.
PSOs will receive feedback on non-existent domains, which may be
similar to existing Organizational Domains. Feedback related to such
cousin domains have a small risk of carrying information related to
an actual Organizational Domain. To minimize this potential concern,
PSD DMARC feedback is best limited to Aggregate Reports. Feedback
Reports carry more detailed information and present a greater risk.
Due to the inherent Privacy and Security risks associated with PSD
DMARC for Organizational Domains in multi-organization PSDs that do
not particpate in DMARC, any Feedback Reporting related to multi-
organizational PSDs ought to be limited to non-existent domains
except in cases where the reporter knows that PSO requires use of
DMARC.
5. Security Considerations
This document does not change the Security Considerations of
[RFC7489] and [RFC7960].
The risks of the issues identified in [RFC7489], Section 12.5,
External Reporting Addresses, are amplified by PSD DMARC. By design,
PSD DMARC causes unrequested reporting of feedback to entities
external to the Organizational Domain. This is discussed in more
detail in Section 4.
6. IANA Considerations
This document does not require any IANA actions.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Kitterman Expires July 18, 2019 [Page 7]
Internet-Draft PSD DMARC January 2019
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
Acknowledgements
TBS
Author's Address
Kitterman Expires July 18, 2019 [Page 8]
Internet-Draft PSD DMARC January 2019
Scott Kitterman
fTLD Registry Services
600 13th Street, NW, Suite 400
Washington, DC 20005
United States of America
Phone: +1 301 325-5475
Email: [email protected]
Kitterman Expires July 18, 2019 [Page 9]