Subject: [ietf-dkim] draft-otis-dkim-tpa-label-00 posted

From: Douglas Otis <[email-masked]>
Date: Wed, 07 Oct 2009 19:32:43 -0700

Here is an update of the tpa draft given a different title.

http://www.ietf.org/id/draft-otis-dkim-tpa-label-00.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-00.html

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Daniel Black <[email-masked]>
Date: Fri, 9 Oct 2009 13:08:08 +1100

> Here is an update of the tpa draft given a different title.
http://www.ietf.org/id/draft-otis-dkim-tpa-label-01.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-01.html

Overall Doug I'd like to say "very well done". You've encapsulated the problem 
statement quite well and provided a justified author domain framework for TPA.

Thanks also for your DNS size measurements - that makes sense to me.

Things I have questions about are:

4.
"In addition, a newline character (0x0A) is appended to the end of the string 
to match a command line generation of SHA1 values".   This sounds likes its 
adding an implementation nicety when I'm not sure all implementations would 
use. Those that don't, could find it inconvenient and a source of errors.

"d=" parameter (does not include the trailing period)." So a d= field could 
contain a trailing period? If this is the case it probably should be cleared 
up in the dkim-signatures RFC rather than being TPA specific.

So the "signing-domain" comes from the d= field of the third party signer?

and "email-address domain" is from the Author Domain (RFC5617)? (not 
explicitly stated). Is so can the same "author domain" terminology be used? 
This would also simplify the wording in section 7.

5.1

Isn't this the same as ADSP based on the section 4 definitions? As an author 
of example.com I put a TPA-Label of:

>From Appendix A:
 ## "isp.com" TPA-Label ##
 _HGSSD3SNMI6635J5743VDJHAJKMPMFIF._adsp._domainkey.example.com. IN TXT
    "dkim=all; tpa=isp.com; scope=F;"

So now I'm allowing isp.com to be a third party sender of example.com. The 
verification of a TPA will use the author domain, example.com, and the 
d=isp.com as the TPA-Label finding this record. This will say that isp.com can 
exist in the From address at the same time as example.com (as the author 
domain). So this scope is for when multiple From address fields are in an 
email and alters the ADSP RFC section 3.

Am I understanding this right?

5.2

small nitpick - only some of resent-* are mailboxes/address-list
http://tools.ietf.org/html/rfc5322#section-3.6.6

Wouldn't resent messages still have valid first party signatures (assuming no 
key rollover)?

"rfc5322"
"The purpose of
   using resent fields is to have the message appear to the final
   recipient as if it were sent directly by the original sender"

If author domain key rollover is a valid consideration maybe only Resent-From 
and Resent-Sender should be specified here as they are the only fields to be 
associated with a third party signature.

5.*

Suggest add a specific maillist scope - mail lists may be run off a domain 
shared with ordinary users. Making it harder for user's to spoof messages by 
scoping to a mailiing List-id could be useful. This assumes the domain has 
some controls preventing the abliltiy of users to add list-id tags but either 
way, TP delegation is based on trust.

suggest text:
{{{
4 - add "L  List-ID"

5.X List-ID Header Field

The "L" scope asserts that the  list-id [rfc2919 section 3] in the List-ID 
header field within a TPA-Label listed domain is authorized to be signed by 
the TPA-Label listed domain.

7 "When a TPA-Label TXT resource record within the From header field has a 
scope tag of "L", the list identifier (list-id) [rfc2919] is within the TPA-
Label listed domain, use of this command by this domain is authorized by the 
Author's Domain."
}}}

5.4

"This scope might be used to better ensure DKIM signatures within messages 
from these hosts are validated."

I was guessing that only valid DKIM-signatures with a d= field should be 
looked at for the purposes of TPA authentication? Where this is or is not the 
intent should maybe be stated (or ruled out of scope).  Which every way is 
chosen I'd avoid making one scope parameter to do with EHLO/HELO commands have 
the additional burden of DKIM signature validation.

5.*
nitpic: TPA-Labeled domain*s* is a list and in the 5.* sections should always 
be referred to in a plural sense.

8.
eventually should contain some updates to rfc5451

Appendix A
 #### 5322.From authorization for TP domains ####
                                _adsp._domainkey.example.com.  IN TXT
    "dkim=all; scope=F:O:M;"

I don't think this form of TP is defined in the document. Could be wrong.

Thanks Doug,

Daniel

---

From: Doug Otis <[email-masked]>
Date: Sun, 11 Oct 2009 19:24:31 -0700

> use. Those that don't, could find it inconvenient and a source of errors.

Unix provides many command-line functions, where strings are terminated 
with '\n'.  Defining the domain as terminated with '\n' permited easy 
use of standard command-line libraries by shell scripts and the like. 
However, there would be less dependency upon OS conventions which can be 
handled as follows:

echo -n isp.com |openssl sha1
3cd04e4acbdafe6e4d4028280fd30994b41991d5

> up in the dkim-signatures RFC rather than being TPA specific.

While many applications assume trailing periods are omitted, the domain 
is defined with the trailing "." being omitted using both text and the 
ABNF description.  RFC4781 defined the lack of trailing period by 
specifying this with ABNF syntax.  It seemed important to ensure this 
mistake is not made by defining this in both text and formula.

> This would also simplify the wording in section 7.

I'll attempt to reduce the number of different ways the same item is 
being used in the text.

>      "dkim=all; tpa=isp.com; scope=F;"

Section 4 defines the record's location, and Section 5 defines the 
meaning of the scope= tag.  I'll provide a clearer breakdown.

> Am I understanding this right?

No. I'll attempt to make this clearer.  ADSP is based upon the domain 
within the From header.  The 'F' scope indicates that the TPA-Label 
listed domain signature can be considered equivalent to an Author Domain 
Signature.  The O, M, and H scopes would be used to provide a 
correlation between the Author Domain (where the TPA-Label is published) 
with that of these other domains.  This correlation could help in 
reducing false positive detection of spam or phishing attempts.

> Wouldn't resent messages still have valid first party signatures (assuming no

Your question represents the same confusion expressed in your previous 
question.  It is clear that the difference between F and M,H,O scopes 
need to be better explained.

> associated with a third party signature.

Agreed, but to ensure when non-From originating headers are used, the 
scope parameter that extends authorization for the use of these headers 
by a third-party domain.  This authorization might help prevent false 
phish detections, for example.

> way, TP delegation is based on trust.

I added the 'L' scope.  Does this look okay?

> be referred to in a plural sense.

I'll change this to a mnemonic.

>                                  _adsp._domainkey.example.com.  IN TXT

Sorry, this was short-hand for Third-Party.  The  needed to fit within 
an RFC line limitation.  I'll change this to 3p.

Thanks for the feedback.

Here is an update of the tpa draft with your suggested changes.

http://www.ietf.org/id/draft-otis-dkim-tpa-label-02.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-02.html

-Doug