ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-otis-dkim-tpa-label-01 posted - comments

2009-10-11 22:27:53
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

<Prev in Thread] Current Thread [Next in Thread>