Subject: [ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Sep 2006 14:02:06 -0700

Sorry,

This repeats a message sent earlier today with the subject: ssp- 
requirements-01 // DKIM Strict definition needed.  There have been  
comments that notice nothing differentiates 4.1 from 4.2.  This was  
discussed previously but not incorporated in the revision.  This  
definition is compatible with terms used in Eric's latest draft as well.

2.  Definitions

Add:

o  DKIM Strict: the state where the domain holder believes that all
    legitimate mail purportedly from the domain are sent with a
    valid DKIM signature and that non-compliant services are avoided.

4.1.  Scenario 1: Bigbank.example.com
...
Was:
,---
|Note that for the foreseeable future, DKIM signature breakage for
|unrestricted use patterns (ie with users and especially where users
|are members of mailing lists) will likely suffer occasional damage in
|transit.  While probably not a large percentage of total traffic, the
|kind (quality) of breakage may be significant for certain usage
|patterns.  As such, this scenario defines a more limited situation
|where the risk of a legitimate piece of mail being mislabeled as
|unsigned outweights the risk of illegitimate mail being delivered in
|the eyes of the sender.
'___

Change to:

:Note that for the foreseeable future, DKIM signature breakage for
:unrestricted use patterns (ie with users and especially where users
:are members of mailing lists) will likely suffer occasional damage in
:transit.  While probably not a large percentage of total traffic, the
:kind (quality) of breakage may be significant for certain usage
:patterns.  As such, this scenario defines a more limited situation
:where the risk of a legitimate piece of mail being mislabeled as
:unsigned outweights the risk of illegitimate mail being delivered in
:the eyes of the sender.  [Rather than indicating a DKIM Signer
:Complete state, DKIM Strict would be used instead.]

-Doug

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

---

From: Jim Fenton <[email-masked]>
Date: Wed, 20 Sep 2006 22:53:18 -0700

In the terminology used in ssp-requirements-01, "Strict" (as used in
allman-dkim-ssp-02) is represented by "signing complete" plus an
expectation that the signature wouldn't be broken, as a mailing list
(for example) might do.  Trying to introduce "strict" here would require
a lot of changes elsewhere in the document that refer to expectations
separately from practices.

However, my reading of 4.1 doesn't make it clear that the stronger
expectation is being used, which I think is the source of confusion when
comparing it with 4.2.

-Jim

Douglas Otis wrote:
> Sorry,
>
> This repeats a message sent earlier today with the subject:
> ssp-requirements-01 // DKIM Strict definition needed.  There have been
> NOTE WELL: This list operates according
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 07:59:02 -0700

It's my opinion that "strict" means far too many things to far too many
people. Instead of rehabilitating the term, I'd far prefer that we pick
something else and really define what it means. I'm not sure that I've
achieved that and would appreciate help, but reverting back to the
handle that nobody seems to agree on doesn't strike me as very helpful.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Sep 2006 10:44:14 -0700

On Sep 21, 2006, at 7:59 AM, Michael Thomas wrote:

> It's my opinion that "strict" means far too many things to far too  
> many people. Instead of rehabilitating the term, I'd far prefer  
> that we pick something else and really define what it means. I'm  
> not sure that I've achieved that and would appreciate help, but  
> reverting back to the handle that nobody seems to agree on doesn't  
> strike me as very helpful.

What is difficult to understand with this definition?  Is a  
definition is needed for non-compliant services?

A list server would be one such non-compliant service when it damages  
initial signatures associated with some email-address.  Possible  
associated email-addresses might include 2822.From and 2821.Mail_From  
when DKIM is also used to ensure DSNs, for example.  This would be  
much safer than a scheme using address path registration, for example.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 11:02:55 -0700

Douglas Otis wrote:

>> many people. Instead of rehabilitating the term, I'd far prefer  that 
>> we pick something else and really define what it means. I'm  not sure 
>> that I've achieved that and would appreciate help, but  reverting 
>> back to the handle that nobody seems to agree on doesn't  strike me 
>> as very helpful.
>
>

How does this differ from scenario #1?

    Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Sep 2006 11:12:54 -0700

On Sep 21, 2006, at 11:02 AM, Michael Thomas wrote:
>>> It's my opinion that "strict" means far too many things to far  
>>> too  many people. Instead of rehabilitating the term, I'd far  
>>> prefer  that we pick something else and really define what it  
>>> means. I'm  not sure that I've achieved that and would appreciate  
>>> help, but  reverting back to the handle that nobody seems to  
>>> agree on doesn't  strike me as very helpful.
>>
>>
>> definition needed for non-compliant services?
>

This definition better pertains to scenario #1 than does DKIM Signer  
Complete which fails to offer assurances that non-compliant services  
are believed to have been avoided.  This defined state allows greater  
clarity when attempting to differentiate between Scenario #1 and #2.   
The term "Strict" was borrowed from Eric's draft.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 11:15:55 -0700

Douglas Otis wrote:

>>>> help, but  reverting back to the handle that nobody seems to  agree 
>>>> on doesn't  strike me as very helpful.
>>>
>>>
>>>

So is this an issue of just wanting to inject the word "strict" 
somewhere into scenario #1?
If so, I've already said why I don't think that's helpful.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Sep 2006 11:46:40 -0700

On Sep 21, 2006, at 11:15 AM, Michael Thomas wrote:
>> This definition better pertains to scenario #1 than does DKIM  
>> Signer  Complete which fails to offer assurances that non- 
>> compliant services  are believed to have been avoided.  This  
>> defined state allows greater  clarity when attempting to  
>> differentiate between Scenario #1 and #2.   The term "Strict" was  
>> borrowed from Eric's draft.
>

The term "DKIM Strict" is an alias for a defined state that excludes  
non-compliant services.

Scenario #1 and #2 must be able to declare a different state to  
ensure proper handling of their messages.  Being able to  
differentiate between these two states allows the 1% of instances  
where different handling of signature failure is desired, without  
potentially jeopardizing the delivery integrity of a domain that  
asserts the "DKIM Signer Complete" state.

In the case of scenario #2, knowing non-complaint services are used  
then permit all such known and well run non-compliant sources.  These  
sources will be rather easy to identify and list.  However, making  
this allowance for Scenario #1 would seriously reduced the desired  
security being sought.  If "DKIM Signer Complete" is allowed, then  
"DKIM Strict" must also be allowed or this introduces a serious  
security flaw when considering how a "DKIM Signer Complete" state  
might be handled in practice.

-Doug

P.S. Neither DKIM Signer Complete or DKIM Strict are likely to prove  
beneficial in practice.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 15:53:43 -0700

Douglas Otis wrote:

>>> Signer  Complete which fails to offer assurances that non- compliant 
>>> services  are believed to have been avoided.  This  defined state 
>>> allows greater  clarity when attempting to  differentiate between 
>>> Scenario #1 and #2.   The term "Strict" was  borrowed from Eric's 
>>> draft.
>>
>>

I've read this three times and can't figure out how it is responsive to my
question.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Sep 2006 16:38:58 -0700

> How does this differ from scenario #1?

Note that DKIM Strict is not currently defined, but should be.   
Another point is that to avoid a serious security issue, there must  
be different states that can be asserted for Scenario 4.1 and 4.2.   
It is also not apparent what differentiates Scenario 4.1 and 4.2.   
The requirements draft currently only defines "DKIM Signer  
Complete."  If you review the definition for "DKIM Strict" the phrase  
"and that non-compliant services are avoided" has been added to the  
definition of "DKIM Signer Complete".  What specifically do you find  
confusing about these definitions?

Perhaps these definitions might help.

o DKIM Friendly: a system, subsystem, or service that does not
   render an existing message's DKIM signature invalid.

o DKIM Strict: the state where the domain holder believes that all
   legitimate mail purportedly from the domain are sent with a
   valid DKIM signature [and all services that are not DKIM Friendly
   are also avoided.]

Use scenarios are clarified by indicating when different states are  
applicable.  You may have noticed a number of comments in this regard.

In 5.3. Practice and Expectation Requirements

There should also be a statement added:

   n.   The Protocol MUST be able to publish a Practice that the
         domain's signing behavior is "DKIM Strict"

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Sep 2006 16:53:16 -0700

> Note that DKIM Strict is not currently defined, but should be. 

Doug, this is completely circular so I give up.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Sep 2006 18:03:12 -0700

> Doug, this is completely circular so I give up.

This is a request that a policy state be _defined_ and indicated as  
_required_ within the 4.1 use scenario and listed in section 5.3.

The 4.1 use scenarios has been made confusing by not alluding to when  
this undefined policy state might apply.  Your suggestive  
descriptions have been unhelpful.

DKIM Signer Complete is not suitable in this 4.1 but is suitable in  
4.2.  A more stringent state is required for 4.1 or we have the  
following problem:

  A- mailing list messages might be accepted when permitting signature
     failures from otherwise trusted mailing lists. (An assumption
     that steps to prevent signature failures have not been taken that
     is not suitable for 4.1)

  B- mailing list messages might be blocked when guarding against
     phishing attempts. (An assumption that steps have been taken to
     prevent signature failure that is not suitable for 4.2)

4.1 requires a policy state that ensures use scenarios 4.1 and 4.2  
can be handled appropriately and that a wrong assumption is not  
made.  Currently this state has not been defined or listed as a  
policy requirement.

What are your reasons for excluding and not defining this stringent  
policy state?

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Sep 2006 11:13:20 +0100

(This thread relates to issue #1358 btw.)

Douglas Otis wrote:
> this undefined policy state might apply.  Your suggestive descriptions 
> have been unhelpful.
> 
> 4.1 requires a policy state that ensures use scenarios 4.1 and 4.2 can 
> be handled appropriately and that a wrong assumption is not made.  
> Currently this state has not been defined or listed as a policy 
> requirement.
> 

Without entering into whether or not your definition is good, one
reason would be a lack of support for the suggested text coupled
with active opposition.

But there is another issue (1357) where Mike and Dave agreed to work
out language to make a clear distinction between the two scenarios
concerned, so if you're right about this, then they'll presumably
just discover that as they try write new text.

Stephen.

PS: I personally still don't understand how any interesting domain
can "avoid" messages passing through signature-breaking services, so
since I don't understand how to do it, I'd have a problem with that
language in any case.