ietf-dkim
[Top] [All Lists]

[ietf-dkim] Review of draft-ietf-dkim-overview-05

2007-07-22 20:35:42
Below are some comments on dkim-overview-05.  I'll start out with some
general comments and then go through section by section.  I'll try to
avoid grammatical nits at this point, although sometimes I just can't
help myself.

General:

The document seems to be inconsistent as to whether it's just being
descriptive of DKIM and its environment or whether it's a normative
document.  The language used seems to be all over the place between
descriptive, "the verifier obtains the domain name from the DKIM header
field,"  non-normative "should" and normative "SHOULD."

There's some inconsistency as to whether SSP is included in this
overview, and where it is, it makes some assumptions about SSP that
haven't been decided yet.

There is little guidance about the use of multiple signatures in a
message.  In particular, an invalid signature shouldn't cause the
message to be treated as unsigned:  there could be other valid signatures.

Top-level structure of the document needs serious work. There are a lot
of subsections that don't fit within the section they're in.

The introductory material seems to go on forever.  The background on the
email administrative structure should be limited to the minimum that is
needed to set the foundation for the rest of the document.


Specifics:

1.1 paragraph 1: Use present, not future, tense.

1.1.1 paragraph 3 s/An attack is made/Suppose an attack is made/ 
"leverage" implies amplification: need a better word.  s/DKIM-based
accreditation/domain-based accreditation/ (and please define
accreditation somewhere).  s/enforce a basic separation/differentiate/

1.1.1 paragraph 4 s/It can also/They can also/  Example of "independent
service"?  s/the basis/a basis/

1.1.1 paragraph 5 s/not signed by email/not signed by DKIM/  Should SSP
be mentioned, since it affects how unsigned mail might be handled?

1.1.2 paragraph 1 s/therefore trusted to be accurate/therefore assumed
to be accurate/

1.1.2 paragraph 5 s/semantic implication of the assertion/semantic
assertion/

1.1.2 paragraph 6 don't understand what is meant by "technical aspect"

1.1.3.1 Under ADMD Examples, why is an ISP an ADMD, unless it is also a
Mail Service Provider?

1.1.4 paragraph 2 delete

1.2 I thought 1.1.1 was all about the goals of DKIM?

1.2.1 Do we want to make any comparisons with SPF or SenderID, even
though they are Experimental?  In particular, they also work at the
domain level.

1.2.1 paragraph 2 s/sign with any domain name/sign with any domain name
for which they have authority/  s/DKIM needs to support/DKIM supports/
This paragraph in particular sounds like a list of requirements (or
deficiencies) for DKIM, rather than what it does, e.g., "DKIM must
support this mode of activity"  s/not visible/not typically visible/

1.2.1 paragraph 3  Ability to send a message without signing is also a
factor in providing anonymity.  s/does not threaten the anonymity of the
user/may not threaten the anonymity/ (a signature from my personal
domain would definitely threaten my anonymity!)

1.2.2 paragraph 2 Need to reword in terms of invalid signatures being
ignored, not treating the message as a whole as (necessarily) unsigned. 
The treatment of failed signatures as not present does not derive from
transparency, but rather from the following consideration:  Message
signatures MAY break in transit, so treating a message with a broken
signature any worse than an unsigned message would tend to discourage
signing.

1.2.2 paragraph 4 Delete "accreditation" since that is done on behalf of
the sender, and this is talking about a list maintained by the receiver.

1.3 SSP should be referenced here.

1.3.1 Don't understand first sentence; perhaps s/associates a domain
name with an address/chooses a sending identity/

1.3.1 paragraph 3: Does this belong in 1.3.3?  The service restriction
isn't nearly as interesting as the key record's restriction of signing
algorithms and perhaps the user-part of the signing address.

1.3.3 first sentence: A signature really associated with a signing
address, specified in the i= tag, although the entity doing the signing
usually does so for all addresses in the domain.  d= is really the place
to look for the key, and may be the same as or sometimes a parent of the
domain-part of i=.

1.3.3 paragraph 4: I have some trouble with the "should use different
sub-domains" (assuming it's trying to be normative).  This is, in
effect, recommending changes in the way organizations address their
email, which I thought we were trying to avoid.  It's also not clear to
me whether reputation services will key off d= or i=; using i= probably
makes it easier to make up subdomain names in order to avoid negative
reputation, but it's fairly easy with d= as well (just requires more key
records).

1.4: Figure 4 doesn't address multiple signatures.

1.4 paragraph 3: s/Unsigned messages/Messages lacking a valid signature
corresponding to the <2822.From> address/

1.4 paragraph 4:  "are treated": is this normative?

2.1.1  There isn't much that's unique about DKIM in terms of crypto
coding considerations.  Isn't there something we can reference?  In
paragraph 4, why would timing attacks be limited to dual-core and
multiprocessor configurations?

2.1.2 paragraph 4: Why would certificate registration make any
difference at all?

2.1.2 Should there be any guidance on delegation of keys?

Should there be a section 2.1.3 giving guidance to verifiers?

2.2 paragraph 2: To whom (the submitter or the email administrator) is
the "operator alert" issued?  I'm mixed about the utility of such
alerts, because the vast majority of non-compliant non-signers will
submit through a completely different path that doesn't do any
checking.  If this is normative, I'd make it a MAY.

2.3 paragraph 2: s/about the message/about the message or the signing
domain/  s/a spammer or other malefactor/an attacker/

2.3 paragraph 4: s/scheme/verifier/  s/reputation data/reputation data
(including locally-maintained whitelists)/

2.5.2.1 talks about what the verifier does, but it's under section 2.5.2
"Signing".

2.5.3.1 paragraph 2: How does the first sentence relate to SSP?

2.5.3.3 paragraph 2:  advocate stripping only those
Authentication-Results header fields that purport to be from the ADMD
doing the stripping.  Otherwise this may break DKIM signatures that sign
Authentication-Results header fields as described under "intermediaries"
in section 2.2.

2.5.5.1 talks about advertising the algorithms that are both being used
dueing a transition period, but 2.5.5.2 does not reference that
advertisement.  Why is it required?

2.5.6.1 paragraph 2: s/principle/principal/

2.5.6.1 doesn't talk about whether either signature signs the other. 
IMO the signatures should be independent, which means that the DKIM
signature must precede the DK signature.

2.5.6.2.  paragraph 2: what is there to see in the section on Signing? 
Are there any SSP issues to consider?

2.6 first bullet: s/files/records/

2.6.1:  First paragraph might also discuss the option of putting the
_domainkey subdomain in a separate zone which is maintained directly by
the email staff.  Second paragraph s/WILL and//

2.6.1.1: bullet 3, what kind of "exposure" do you mean?

2.6.1.3: it was a goal (of IIM, anyway) not to require domains to change
their addressing practices, such as this describes.  Maybe we didn't
achieve that, but the ability for an attacker using his/her own domain
to create a new subdomain and get a fresh reputation brings the
reputation-silo-via-subdomain issue into question.  I thought we were
considering ways of maintaining reputation as out-of-scope for the WG? 
In other words, I wouldn't expect that reputation providers will
necessarily work this way.

2.6.1.4: This uses the term "third-party" in a different meaning than
its use in SSP.  We should resolve this.

2.6.3: Why is the section on Mailing list manager developers" under
"On-going operations"?  There should be some guidance on what signing
address should be used by mailing lists: is it the sender, list-ID,
etc.?  owner-list(_at_)example(_dot_)com, list(_at_)example(_dot_)com, or
list-bounces(_at_)example(_dot_)com?

2.7.1: "...can be presumed to be spurious".  Not so; messages could
originate from the domain, be sent to a mailing list that breaks the
signature, and back to the same or other users in the originating domain.

2.7.2.1: I don't understand what these are.  Accreditations?

Missing Security Considerations and IANA Considerations sections.

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

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-dkim] Review of draft-ietf-dkim-overview-05, Jim Fenton <=