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
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6541 Cloudmark, Inc.
Category: Experimental February 2012
ISSN: 2070-1721
<span class="h1">DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures</span>
Abstract
This experimental specification proposes a modification to DomainKeys
Identified Mail (DKIM) allowing advertisement of third-party
signature authorizations that are to be interpreted as equivalent to
a signature added by the administrative domain of the message's
author.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6541">http://www.rfc-editor.org/info/rfc6541</a>.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Kucherawy Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Definitions .....................................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Key Words ..................................................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Email Architecture Terminology .............................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Roles and Scope .................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Queries and Replies .............................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Hash Selection .............................................<a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. Extension to DKIM ..........................................<a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. ATPS Query Details .........................................<a href="#page-5">5</a>
<a href="#section-4.4">4.4</a>. ATPS Reply Details .........................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Interpretation ..................................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Relationship to ADSP ............................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. Experiment Process ..............................................<a href="#page-8">8</a>
<a href="#section-8">8</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#section-8.1">8.1</a>. ATPS Tag Registry ..........................................<a href="#page-9">9</a>
<a href="#section-8.2">8.2</a>. Email Authentication Methods Registry Update ..............<a href="#page-10">10</a>
<a href="#section-8.3">8.3</a>. Email Authentication Result Names Registry Update .........<a href="#page-10">10</a>
<a href="#section-8.4">8.4</a>. DKIM Signature Tag Specifications Registry ................<a href="#page-12">12</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-9.1">9.1</a>. Hash Selection ............................................<a href="#page-12">12</a>
<a href="#section-9.2">9.2</a>. False Privacy .............................................<a href="#page-12">12</a>
<a href="#section-9.3">9.3</a>. Transient Security Failures ...............................<a href="#page-13">13</a>
<a href="#section-9.4">9.4</a>. Load on the DNS ...........................................<a href="#page-13">13</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-13">13</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-13">13</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-14">14</a>
<a href="#appendix-A">Appendix A</a>. Example Query and Reply ...............................<a href="#page-15">15</a>
<a href="#appendix-B">Appendix B</a>. Choice of DNS RR Type .................................<a href="#page-15">15</a>
<a href="#appendix-C">Appendix C</a>. Acknowledgements ......................................<a href="#page-16">16</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-DKIM">DKIM</a>] defines a mechanism for transparent domain-level signing of
messages for the purpose of declaring that a particular
ADministrative Management Domain (ADMD) takes some responsibility for
a message.
DKIM, however, deliberately makes no binding between the DNS domain
of the Signer and any other identity found in the message. Despite
this, there is an automatic human perception that an Author Domain
Signature (one for which the <a href="./rfc5322">RFC5322</a>.From domain matches the DNS
domain of the Signer) is more valuable or trustworthy than any other.
To enable a third party to apply DKIM signatures to messages, the
DKIM specification suggests delegation to a third party of either
subdomains or private keys, so that the third party can add DKIM
<span class="grey">Kucherawy Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
signatures that appear to have been added by the Author ADMD. Absent
is a protocol by which an Author ADMD can announce that messages
bearing specific valid DKIM signatures on its mail, which are added
by other ADMDs, are to be treated as if they were signed by the
Author ADMD itself. This memo presents an experimental mechanism for
doing so, called Authorized Third-Party Signatures (ATPS).
ATPS augments the semantics of DKIM by providing to the Verifier
multiple identifiers rather than one. Specifically, it validates the
identifier found in the DKIM signature, and then provides the
<a href="./rfc5322">RFC5322</a>.From domain for evaluation.
This memo also registers, per [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>], the means to indicate to
agents downstream of the Verifier that a third-party signature
verification occurred.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Definitions</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Key Words</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Email Architecture Terminology</span>
Readers are advised to be familiar with the material and terminology
discussed in [<a href="#ref-MAIL" title=""Internet Message Format"">MAIL</a>] and [<a href="#ref-EMAIL-ARCH" title=""Internet Mail Architecture"">EMAIL-ARCH</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Roles and Scope</span>
The context of this protocol involves the following roles:
o ADministrative Management Domains (ADMDs), whose DNS domain
name(s) appear in the <a href="./rfc5322">RFC5322</a>.From field of a [<a href="#ref-MAIL" title=""Internet Message Format"">MAIL</a>] message;
o ATPS Signers, which apply [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>] signatures using their own
domains, but on behalf of the message Author's ADMD; and
o the Verifier, who implements the signature validation procedures
described in [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>].
An ADMD implements this protocol if it wishes to announce that a
signature from any in a set of specified DNS domains is to be
considered equivalent to one from the ADMD itself. For example, an
ADMD might wish to delegate signing authority for its DNS domain to
an approved messaging service provider without doing the work of key
transfer described in <a href="#appendix-B.1.1">Appendix B.1.1</a> of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]. An authorized ATPS
<span class="grey">Kucherawy Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
Signer makes a claim of this relationship via new tags in the DKIM
signature, and the ADMD confirms this claim by publishing a specific
TXT record in its DNS.
A Verifier implements this protocol if it wishes to ensure that a
message bears one or more signatures from sources authorized to sign
mail on behalf of the ADMD, and identify for special treatment mail
that meets (or does not meet) that criterion. It will do so by
treating the Signer's authorization on behalf of the Author's ADMD to
mean that the Signer's signature is equivalent to one affixed by the
Author's ADMD.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Queries and Replies</span>
This section describes in detail the queries issued, the replies
received, and how they should be interpreted and applied.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Hash Selection</span>
The Author's ADMD will indicate authorization of a third party to
sign its mail via the presence of a DNS TXT record that contains an
encoding of the third party's DNS domain name. There are two
supported methods for doing so -- one that involves a plain copy of
the third party's DNS domain name, and one that involves an encoded
version of the name. The encoding mechanism is provided so that any
domain name can be added to the DNS in a fixed length, so that longer
third-party domain names are not excluded from participation because
of the overall length limit on a DNS query.
If selected, the encoding mechanism requires constructing a digest of
the third party's DNS domain name. The Author ADMD MUST select a
digest ("hash") method currently supported by DKIM (see Section 7.7
of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]), and this selection needs to be communicated to the ATPS
Signer, as it is used in generation of the third-party signatures.
Where the encoding mechanism is not used, the ATPS Signer MUST use a
hash name of "none".
The full DNS mechanism is specified in <a href="#section-4.3">Section 4.3</a>.
<span class="grey">Kucherawy Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Extension to DKIM</span>
[<a id="ref-DKIM">DKIM</a>] signatures contain a "tag=value" sequence. This protocol will
add additional tags called "atps" and "atpsh".
When the ATPS Signer generates a DKIM signature for another ADMD, it
MUST put its own domain in the signature's "d" tag, and include an
"atps" tag that has as its value the domain name of the ADMD on whose
behalf it is signing.
The tag name that carries the name of the selected hash algorithm is
"atpsh". This tag MUST also be included, as it is required as part
of the algorithm that will be enacted by the Verifier.
The formal syntax definition, per [<a href="#ref-ABNF" title=""Augmented BNF for Syntax Specifications: ABNF"">ABNF</a>], is as follows:
dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name
dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP
( "none" / key-h-tag-alg )
"domain-name" and "key-h-tag-alg" are defined in [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]. Note that
according to [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>], internationalized domain names are to be encoded
as A-labels, as described in Section 2.3 of [<a href="#ref-IDNA" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">IDNA</a>].
The registration for these tags can be found in <a href="#section-8">Section 8</a>.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. ATPS Query Details</span>
When a [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>] signature including an "atps" tag is successfully
verified, and is considered acceptable to the Verifier according to
any local policy requirements (which are not discussed here or in
[<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]), the Verifier compares the domain name in the value of that
tag with the one found in the <a href="./rfc5322">RFC5322</a>.From field of the message. The
match MUST be done in a case-insensitive manner.
If they do not match, the "atps" tag MUST be ignored.
If they do match, the Verifier issues a DNS TXT query, as specified
below, looking for confirmation by the Author ADMD that the ATPS
Signer is authorized by that ADMD to sign mail on its behalf. Where
multiple DKIM signatures including valid "atps" tags are present,
these queries MAY be done in any order or MAY be done in parallel.
Where the <a href="./rfc5322">RFC5322</a>.From field contains multiple addresses, this
process SHOULD be applied if the "atps" tag's value matches any of
the domains found in that field. These MAY be done in any order.
<span class="grey">Kucherawy Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
Note that the algorithm uses hashing, but this is not a security
mechanism. See <a href="#section-9.2">Section 9.2</a> for discussion.
The name for the query is constructed as follows:
1. Select the hash algorithm from the "atpsh" tag in the signature.
If the hash algorithm specified does not appear in the list
registered with IANA as one valid for use with DKIM (see
Section 7.7 of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]), and is not the reserved name "none" as
described above, abort the query.
2. Extract the value of the "d=" tag from the signature.
3. Convert any uppercase characters in that string to their
lowercase equivalents.
4. If the selected hash algorithm is not "none", apply the following
additional steps:
A. Feed the resulting string to the selected hash algorithm.
B. Convert the output of the hash to a string of printable ASCII
characters by applying base32 encoding as defined in
Section 6 of [<a href="#ref-BASE32" title=""The Base16, Base32, and Base64 Data Encodings"">BASE32</a>]. The base32 encoding is used because
its output is restricted to characters that are legal for use
in labels in the DNS, and it is evaluated the same way in the
DNS whether encoded using uppercase or lowercase characters.
5. Append the string "._atps."
6. Append the domain name found in the "atps" tag of the validated
signature.
The query's formal syntax definition, per [<a href="#ref-ABNF" title=""Augmented BNF for Syntax Specifications: ABNF"">ABNF</a>], is as follows:
atps-query = ( 1*63BASE32 / domain-name )
%x2e.5f.61.74.70.73.2e domain-name
BASE32 = ( ALPHA / %x32-37 )
The width limit of 63 on the base32 encoding is based on the maximum
label limit as defined in Section 2.3.4 of [<a href="#ref-DNS" title=""Domain names - implementation and specification"">DNS</a>].
See <a href="#appendix-A">Appendix A</a> for an example of a query construction.
<span class="grey">Kucherawy Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. ATPS Reply Details</span>
In the descriptions below, the label NOERROR symbolizes DNS response
code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1
of [<a href="#ref-DNS" title=""Domain names - implementation and specification"">DNS</a>] for further details.
At this time, only three possibilities need to be identified in this
specification:
o An answer is returned (i.e., [<a href="#ref-DNS" title=""Domain names - implementation and specification"">DNS</a>] reply code NOERROR with at
least one answer) containing a valid ATPS reply. In this case,
the protocol has been satisfied and the Verifier can conclude that
the signing domain is authorized by the ADMD to sign its mail.
Further queries SHOULD NOT be initiated.
o No answer is returned (i.e., [<a href="#ref-DNS" title=""Domain names - implementation and specification"">DNS</a>] reply code NXDOMAIN, or NOERROR
with no answers), or one or more answers have been returned as
described above but none contain a valid ATPS reply. In this
case, the Signer has not been authorized to act as a third-party
Signer for this ADMD, and thus the Verifier MUST continue to the
next query, if any.
o An error is returned (i.e., any other [<a href="#ref-DNS" title=""Domain names - implementation and specification"">DNS</a>] reply code). It is no
longer possible to determine whether or not this message satisfies
the ADMD's list of authorized third-party Signers. The Verifier
SHOULD stop processing and defer the message for later processing,
such as requesting a temporary failure code from the Mail Transfer
Agent (MTA).
If all queries are completed and return either NXDOMAIN or NOERROR
with no answers, then the Signer was not authorized by the ADMD.
A valid ATPS reply consists of a sequence of tag=value pairs as
described in Section 3.2 of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]. The following tags and values
are currently supported in ATPS records:
d: Domain (plain-text; RECOMMENDED). This tag includes a plain-text
copy of the DNS domain being authorized as an ATPS Signer. This
is included to assist with collision detections; for example, if
the base32 encoding of this name is not the same as the base32
portion of the query, or more simply if this name is not the same
as that found in the "atps" tag, a hash collision could have
occurred. Its use where no name hashing has occurred is
redundant. The ABNF is as follows:
atps-d-tag = %x64 [FWS] "=" [FWS] domain-name
; FWS is defined in [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]
<span class="grey">Kucherawy Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
v: Version (plain-text; REQUIRED). This tag indicates the version of
the ATPS specification to which the record complies. The record
MUST be ignored if the value is not "ATPS1". The ABNF is as
follows:
atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31
; FWS is defined in [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Interpretation</span>
For each DKIM signature that verifies (see Section 6 of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>]), if a
Verifier succeeds in confirming that the Author's ADMD authorized the
ATPS Signer using this protocol, then the Verifier SHOULD evaluate
the message as though it contained a valid signature from the
Author's ADMD. It MAY also independently evaluate the ATPS Signer
when determining message disposition.
This assertion is based on the fact that the ADMD explicitly endorsed
the ATPS Signer. Therefore, a module assessing reputation that is
based on DKIM signature verification SHOULD apply the reputation of
the Author's ADMD domain instead of, or in addition to, that of the
ATPS Signer domain.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Relationship to ADSP</span>
[<a id="ref-ADSP">ADSP</a>] defined a protocol by which the owner of an Author Domain can
advertise a request to message receivers that messages bearing no
valid author signature be treated with suspicion or even discarded.
A Verifier implementing both Author Domain Signing Practices (ADSP)
and ATPS MUST test ATPS first. If ATPS indicates a valid delegation,
the Verifier MUST act, with respect to ADSP, as though the message
has a valid Author Domain Signature (because that's what the
delegation means), and no ADSP test is required.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Experiment Process</span>
The working group that developed DKIM considered a third-party
mechanism such as this one to be controversial, in terms of need and
practicality, and decided that an alternative mechanism was
sufficient. However, this was not based on actual experience, as
there is no specific history on this question. Thus, this experiment
was devised.
<span class="grey">Kucherawy Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
The experimental protocol described here has been implemented as an
extension to DKIM in two software products, one of which is open
source and seeing increasingly wide use. It is included there to
allow customers of those systems to make use of it if they believe
such third-party assertions are useful to the overall DKIM mechanism.
Further adoption as part of the experiment is welcome and encouraged.
Use of the protocol and anecdotes of how it affects the overall DKIM
experience will be collected by those implementers and the author of
this memo. Those participating in the experiment are also advised to
observe and report the impact of what is discussed in <a href="#section-9.4">Section 9.4</a>,
especially with respect to MTA latency that may be introduced.
If the response is substantial and positive, advancement along the
Standards Track might be warranted.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This section enumerates requested IANA actions.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. ATPS Tag Registry</span>
IANA has created an Authorized Third-Party Signature (ATPS) Tag
Registry, under the DomainKeys Identified Mail (DKIM) Parameters
group, to enumerate the tags that are valid for use in ATPS records.
New registrations or updates MUST be made in accordance with the
"Specification Required" guidelines described in [<a href="#ref-IANA" title="">IANA</a>]. Such
registry changes MUST contain the following information:
1. Name of the tag being registered or updated
2. The document where the specification is created or updated
3. The status of the tag, one of "active" (tag is in current use),
"deprecated" (tag is in current use but its use is discouraged),
or "historic" (tag is no longer in use)
The registry's initial entries are below:
+-----+------------+--------+
| Tag | Reference | Status |
+-----+------------+--------+
| d | [<a href="./rfc6541">RFC6541</a>] | active |
+-----+------------+--------+
| v | [<a href="./rfc6541">RFC6541</a>] | active |
+-----+------------+--------+
<span class="grey">Kucherawy Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Email Authentication Methods Registry Update</span>
The following has been added to the Email Authentication Methods
registry (in the Email Authentication Parameters group) established
by [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>] as per [<a href="#ref-IANA" title="">IANA</a>]:
Method: dkim-atps
Defined In: [<a href="./rfc6541">RFC6541</a>]
ptype: header
property: from
value: contents of the [<a href="#ref-MAIL" title=""Internet Message Format"">MAIL</a>] From: header field, with comments
removed
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Email Authentication Result Names Registry Update</span>
The following have been added to the Email Authentication Result
Names registry (in the Email Authentication Parameters group)
established by [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>] as per [<a href="#ref-IANA" title="">IANA</a>]:
Code: none
Existing/New Code: existing
Defined In: [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>]
Auth Method: dkim-atps
Meaning: No valid DKIM signatures were found on the message bearing
"atps" tags.
Code: pass
Existing/New Code: existing
Defined In: [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>]
Auth Method: dkim-atps
Meaning: An ATPS evaluation was performed, and a valid signature
from an authorized third party was found on the message.
<span class="grey">Kucherawy Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
Code: fail
Existing/New Code: existing
Defined In: [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>]
Auth Method: dkim-atps
Meaning: All valid DKIM signatures bearing an "atps" tag either did
not reference a domain name found in the <a href="./rfc5322">RFC5322</a>.From field, or
the ATPS test(s) performed failed to confirm a third-party
authorization.
Code: temperror
Existing/New Code: existing
Defined In: [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>]
Auth Method: dkim-atps
Meaning: An ATPS evaluation could not be completed due to some error
that is likely transient in nature, such as a temporary DNS error.
A later attempt might produce a final result.
Code: permerror
Existing/New Code: existing
Defined In: [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>]
Auth Method: dkim-atps
Meaning: An ATPS evaluation could not be completed due to some error
that is not likely transient in nature, such as a permanent DNS
error. A later attempt is unlikely to produce a final result.
<span class="grey">Kucherawy Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. DKIM Signature Tag Specifications Registry</span>
The following have been added to the DKIM Signature Tag
Specifications registry (in the DomainKeys Identified Mail (DKIM)
Parameters group) established by [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>] as per [<a href="#ref-IANA" title="">IANA</a>]:
+-------+-----------+--------+
| Type | Reference | Status |
+-------+-----------+--------+
| atps | [<a href="./rfc6541">RFC6541</a>] | active |
+-------+-----------+--------+
| atpsh | [<a href="./rfc6541">RFC6541</a>] | active |
+-------+-----------+--------+
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This section discusses potential security issues related to this
experimental protocol.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Hash Selection</span>
The selection of the hash algorithm to be used (see <a href="#section-4.1">Section 4.1</a>) has
security implications, as weaker algorithms have more risk of
collision, meaning a second DNS domain name could in theory be
constructed to appear to have been authorized by the Author ADMD.
At the time of publication of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>], use of SHA256 was preferred
over SHA1 for this reason, though support for both has been
maintained. See Section 3.3 of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>] for additional discussion.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. False Privacy</span>
The fact that the authorized third-party domain name is hashed and
then encoded with base32 might give some the false sense that the
relationship between the two parties is somehow protected. This is
not the case. Indeed, the very purpose of this protocol is to make
it possible for such relationships to be discovered, so such an
obscuration would make that process more difficult without a shared
secret delivered out-of-band to message verifiers (which also adds
further complexity). Rather, the hash and encode steps are done
merely to convert any third-party domain name to a fixed width in the
construction of the DNS query.
<span class="grey">Kucherawy Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. Transient Security Failures</span>
Approving a third-party Signer exposes the ADMD to the risk that the
third-party Signer becomes compromised and then begins to sign
malicious or nuisance messages on behalf of the ADMD. This can
obviously reflect negatively on the ADMD, and the impact of this can
become more severe as automated domain reputation systems are
developed and deployed. Thorough vetting and monitoring practices by
ADMDs of third-party Signers will likely need to become the norm.
<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>. Load on the DNS</span>
A Verifier participating in DKIM, ADSP, and ATPS will now issue a
number of TXT queries to the DNS equal to as many as one (for the
ADSP query) plus the number of signatures on the message (one for
each key that is to be verified) plus the number of signatures that
validated and that also bear an "atps" tag. This is in addition to
any PTR and A queries the MTA might issue at the time the actual
message relaying or delivery is initiated. Obviously, this can be
burdensome on the DNS at both ends, and waiting for that number of
queries to return when they are issued in parallel could trigger
timeouts in the MTA.
An alternative that has not yet been explored is the storage of the
ATPS data at a specific URL tied to the Author's domain name. This
would alleviate pressure on the DNS at the expense of requiring the
ADMD to operate a web server (which has its own security
implications) and the addition of the establishment of a TCP
connection. Moreover, the Verifier would be well advised to
implement caching of this data to prevent ATPS from being used as a
denial-of-service vector.
See Section 8.5 of [<a href="#ref-DKIM" title=""DomainKeys Identified Mail (DKIM) Signatures"">DKIM</a>] for further discussion of DNS-related
issues.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-ABNF">ABNF</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
January 2008.
[<a id="ref-AUTHRES">AUTHRES</a>] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", <a href="./rfc5451">RFC 5451</a>, April 2009.
[<a id="ref-BASE32">BASE32</a>] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", <a href="./rfc4648">RFC 4648</a>, October 2006.
<span class="grey">Kucherawy Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
[<a id="ref-DKIM">DKIM</a>] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy,
Ed., "DomainKeys Identified Mail (DKIM) Signatures",
<a href="./rfc6376">RFC 6376</a>, September 2011.
[<a id="ref-DNS">DNS</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<a id="ref-EMAIL-ARCH">EMAIL-ARCH</a>] Crocker, D., "Internet Mail Architecture", <a href="./rfc5598">RFC 5598</a>,
July 2009.
[<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-MAIL">MAIL</a>] Resnick, P., Ed., "Internet Message Format", <a href="./rfc5322">RFC 5322</a>,
October 2008.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-ADSP">ADSP</a>] Allman, E., Fenton, J., Delany, M., and J. Levine,
"DomainKeys Identified Mail (DKIM) Author Domain Signing
Practices (ADSP)", <a href="./rfc5617">RFC 5617</a>, August 2009.
[<a id="ref-IANA">IANA</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-IDNA">IDNA</a>] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document
Framework", <a href="./rfc5890">RFC 5890</a>, August 2010.
<span class="grey">Kucherawy Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Example Query and Reply</span>
This section presents an example of the use of this protocol to query
for a third-party authorization and discusses the interpretation of
the result.
Presume a message for which the <a href="./rfc5322">RFC5322</a>.From domain is "example.com",
and it bears two valid signatures, from "one.example.net" and from
"two.example.net", each with an "atps" tag whose value is
"example.com", and an "atpsh" tag whose value is "sha1". The
following actions are taken:
1. A SHA1 hash of "one.example.net" is computed and then converted
to printable form using base32 encoding, resulting in the string
"QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6".
2. A TXT query is issued to
"QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com".
3. If a valid reply arrives, the algorithm stops with [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>]
result "pass". If a DNS error code other than NXDOMAIN is
returned, the algorithm stops with a result of "temperror" or
"permerror" as appropriate.
4. A SHA1 hash of "two.example.net" is computed and then converted
to printable form using base32 encoding, resulting in the string
"ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX".
5. A TXT query is issued to
"ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com".
6. If a valid reply arrives, the algorithm stops with [<a href="#ref-AUTHRES" title=""Message Header Field for Indicating Message Authentication Status"">AUTHRES</a>]
result "pass". If a DNS error code other than NXDOMAIN is
returned, the algorithm stops with a result of "temperror" or
"permerror" as appropriate.
7. As there are no valid signatures left to test, the algorithm
stops with an "unknown" result.
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Choice of DNS RR Type</span>
It was proposed that this work appear within the DNS under a new
Resource Record (RR) Type. Although this is possibly an appropriate
thing to do, consideration was also given to the fact that major
portions of DKIM already use an ASCII-based "tag=value" syntax, and
store key and ADSP data in the DNS using TXT resource records. To
enable re-use of existing DKIM code, it was decided to re-use the TXT
message scheme.
<span class="grey">Kucherawy Experimental [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6541">RFC 6541</a> DKIM ATPS Experiment February 2012</span>
<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>. Acknowledgements</span>
The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark
Martinec, and Phil Pennock for their review and constructive
criticism of this proposal.
The author also wishes to acknowledge Doug Otis and Daniel Black for
their original document, upon which this work was based.
Author's Address
Murray S. Kucherawy
Cloudmark, Inc.
128 King St., 2nd Floor
San Francisco, CA 94107
US
Phone: +1 415 946 3800
EMail: msk@cloudmark.com
Kucherawy Experimental [Page 16]
</pre>
|
