Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-03

From: Michael Thomas <[email-masked]>
Date: Fri, 06 Apr 2007 12:04:13 -0700

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

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 06 Apr 2007 13:02:13 -0700

Replies inline...

> is not something that they control (= practice).

Good; that makes it clear you're talking about outgoing mail.
> conflicts with the ssp draft.

It was the word "looks" that bothered me.  How about, "...such that it 
treats the message with additional caution."  That avoids the s-word 
entirely (although in fact it probably doesn't matter).
> coincide is largely a question of how you lay out your namespace.

Fair enough; you're focusing on the class, which is legitimate, and I 
was focusing on the messages themselves.

> PS, etc are for actual protocols. Also: plenty of informational rfc's

But this is a requirements document, not a protocol specification itself.
>> database sense, not the crypto sense) to the policy.

"Trust" is such an overused word that I would prefer the wording, 
"...will be used as the reference point from which to fetch the 
published information."

>> I'm not sure "transport scenarios" fits that well with the content of 

How about "Caching Considerations"?
> want to get too elaborate on the taxonomy.

I would just have them in the Requirements section; I don't think 
everything that is a requirement needs to be traceable to a scenario.  
Security, for example, isn't a scenario because you always need it; it 
isn't independent  of the other scenarios.
>
>> 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?

Sorry, bad choice of words on my part.  I mean that the domain holder 
can publish a key record corresponding to a key under control of someone 
else (an email service provider, for example).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html