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

[Stephen Farrell]

(This thread relates to issue #1358 btw.)

Douglas Otis wrote:
> 
> On Sep 21, 2006, at 4:53 PM, Michael Thomas wrote:
>> Douglas Otis wrote:
>>> On Sep 21, 2006, at 3:53 PM, Michael Thomas wrote:
>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> What is difficult to understand with this definition?  Is a 
>>>>> definition needed for non-compliant services?
>>>>
>>>> How does this differ from scenario #1?
>>>
>>> Note that DKIM Strict is not currently defined, but should be.
>>
>> 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?

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.