On 10/8/09 7:08 PM, Daniel Black wrote: > On Thursday 08 October 2009 13:32:43 Douglas Otis wrote: > > 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.
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 > "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. 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. > 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. I'll attempt to reduce the number of different ways the same item is being used in the text. > 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;" Section 4 defines the record's location, and Section 5 defines the meaning of the scope= tag. I'll provide a clearer breakdown. > 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? 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. > 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)? 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. > "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. 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. > 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. I added the 'L' scope. Does this look okay? > 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. I'll change this to a mnemonic. > 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;" 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 > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
