[ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-03

[Michael Thomas]

No comment means I'll roll it in somehow...

Jim Fenton wrote:
> With apologies that this didn't get done before (I think) the last day 
> of WG last call, here are my comments on ssp-requirements-03.
> 1. Introduction
> 
> "first party" is used here before being introduced.  Should probably 
> either refer ahead to the glossary or use a term like "author" that is 
> less jargony.
> 
> "a priori" is overused, perhaps inappropriately.  Suggest s/there is no 
> expectation of a priori knowledge/there is in general no knowledge/   
> Also "a priori invalid" doesn't make sense, because it was observed, and 
> we haven't defined what "invalid" is.
> 
> 2. Definitions
> 
> s/Listid/List-id/
> s/adjacent SMTP./adjacent SMTP server./
> 
> 3.1
> 
> My first problem is with the title of this section:  Is "All Mail Signed 
> with DKIM" really a problem scenario?  I think the problem scenario is 
> really that an unsigned message was received, and the recipient has to 
> figure out what to do about that.
> 
> s/insured/ensured/
> 
> Paragraph 2, "what their expectations are for unsigned mail." sounds 
> like a question about that this domain does with their incoming mail, 
> not what their practices are with respect to signing.

How about "what their expectations are for unsigned mail purportedly
originating from their domain". It's not strictly a practice per se,
it's what their expectations are wrt the ultimate survivability which
is not something that they control (= practice).
> 
> Paragraph 3, s/allowed/allows/
> 
> Paragraph 5, s/bias filters/bias its filters/
> 
> Following paragraph 5 is a numbered list of steps that should be 
> preceded by some introductory text.
> 
> Step 1, s/purportedly sends/is sent/
> 
> Step 4, "looks somewhat more suspicious" sounds like a UI issue, and 
> conflicts with the definition of Suspicious that we're likely to be 
> using in the SSP draft itself

First it doesn't have to have anything to do with a UI, and second
I'd say that you have it cart before horse here about suspicious:
if there's a problem, you need to tell me what it is, not that it
conflicts with the ssp draft.
.
> 
> 3.2
> 
> Paragraph 1 first sentence is worded as though a particular class of 
> mail is the target; the domain is actually the target.

I'd say that's debatable. It is transactional mail that is the prime
problem, not the day-to-day conversational mail. Whether those two
coincide is largely a question of how you lay out your namespace.

> 
> Paragraph 2 should perhaps mention the usage patterns of such domains, 
> that they don't typically send to mailing lists, which are a significant 
> contributor to signature breakage.
> 
> Paragraph 3 Informative Note:  Isn't this whole document informative? 
> (Applies to other informative notes too)

No, the document still lays out normative behavior for the protocol.
PS, etc are for actual protocols. Also: plenty of informational rfc's
have normative language.

> 
> Again, the numbered list of steps could use some introduction.
> 
> Step 4, same comment about use of "suspicious".
> 
> 4.2
> 
> SSP's is awkward; I would word things to avoid this ("Sender Signing 
> Practices's" is a mouthful!)  Same comment elsewhere.
> 
> Paragraph 1, s/SSP's client will generally be deployed/SSP lookups will 
> generally be performed/
> 
> The 4844.From address isn't a "trust basis" but rather a key (in the 
> database sense, not the crypto sense) to the policy.

I'm not groking this.

> 
> Where does this section talk about determinism (first word of the title)?
> 
> 4.4
> 
> Paragraph 3, "strong practice" isn't defined anywhere.  You might want 
> to say "signing complete" practice or something like that.
> 
> 4.5
> 
> I'm not sure "transport scenarios" fits that well with the content of 
> this section.

Suggest away...


> Paragraph 2, s/sadly a vector for those sending mail for anti-social 
> reasons/unfortunately an attack vector for those wishing to spoof email 
> addresses/
> 
> 4.6 through 4.9
> 
> Are these really deployment scenarios?  They don't read that way to me.

If you can think of another bucket to put them under... I mainly didn't
want to get too elaborate on the taxonomy.


>
> 5.1
> 
> Item 4, "The process of obtaining the parent domain's practices MUST 
> complete..." is a duplicate of item 2.  The following sentence, "In 
> widening the scope..." isn't a requirement at all but a discussion of 
> implementations.

This is going to get rewritten in 2, so it probably won't be a dup after


> 
> 5.3
> 
> The whole thing about the X-Silly header field makes it sound like there 
> is a requirement here that SSP has to be able to publish expectations 
> about presence of header fields.  Is that requirement intended?


Yeah, I'll reword this.

> Item 1, do you mean the entire RFC2822.From address or just the domain 
> part?

just domain.

> 
> Item 2 sounds like a requirement for the protocol but really it's a 
> requirement that the specification define this, correct?

yes.

> 
> Item 6 should also mention the ability of the domain holder to delegate 
> individual keys by registering them.  Isn't there something else we can 
> reference that describes the way to do this delegation?

Registering them?

> 
> Item 6 doesn't reference any scenarios.  I think it refers to Deployment 
> Scenario 1
.
> 
> Item 10, I disagree that this requirement should stand.
> 
> 5.4
> 
> Item 1, s/able to extend/extensible/
> 
> 6.
> 
> Item 1, where is the requirement?

Good question :)

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