Subject: [ietf-dkim] Issue:1519 SSP-01 Unnecessary constraint on i= when asserting "strict"

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Jan 2008 12:44:13 -0800

Signature compliance changes when a From domain's SSP indicates  
"strict".

When a message has a valid unconstrained signature of the From domain,  
verifiers should consider this domain's signature authoritative for  
the domain's policies.  The only instance where the i= parameter  
should play a role in "strict" policy compliance would be when the key  
restricts local-parts via the g= parameter.

As SSP's "strict" is currently defined, although a message might be  
signed by the From domain using an unrestricted key, when the i=  
parameter is not "on-behalf-of" the From header, it will not provide  
compliance with a "strict" policy.  The From domain should validate  
sources within their domain prior to signing.  Hopefully this  
signature will also indicate the validated source.   A "strict" policy  
should not interfere in a signature's ability to indicate which source  
had been validated.

SSP's "strict" creates an unnecessary i= parameter requirement that  
will cause:

- unexpected corner cases such as when -

  a) office administrators send "on-behalf-of" their boss (Sender)/From
  ...

Mitigating corner cases will require:

- use of ambiguous signatures where the i= parameter is excluded

- use of multiple signatures

SSP policy should strive to minimize disruption.  There is no  
justification for "strict" policy compliance to invalidate any  
unrestricted signature of the From domain.  After all, unrestricted  
keys are able to sign any header and _must_ be utilized by trustworthy  
systems.  When unrestricted keys are used, it is also reasonable to  
assume that the domain's signing policies were applied prior to  
signing.  SSP's "strict" definition unreasonably constrains how the i=  
parameter might be utilized for unrestricted keys.  It is not  
reasonable to assume domains will have mitigated the exceptions  
created by the SSP definition for "strict" and its additional i=  
parameter requirements.  It is only reasonable to assume DKIM  
practices are based upon RFC 4871.  As currently defined, SSP is not  
compliant with RFC 4871.

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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 10 Jan 2008 15:58:46 -0800

This is mixing together two issues.  The question of what constitutes an
Originator (now Author) Signature applies to all SSP practices because
it's the basis for deciding whether to look up SSP at all.  For that
reason, I'd suggest leaving "strict" out of it.

So the question then is whether the local-part of i= should be part of
the match against the From address to determine whether it's an Author
Signature.  If I understand your proposal, you're suggesting that we
only match the local-part if the g= of the key is constrained (the key
isn't valid for all addresses in the domain).  If this were done, the
input to SSP would be not just the message itself, the SSP record, and
information about validity of signatures in the message.  It would also
be necessary to have information from the selector records about the g=
value of each.  In all other respects, the selector data is only used
foe verifying the signature itself.

Signers that have a key that is unconstrained always have the option to
sign with an empty local-part.  Basing the decision on the presence of
g= in the key means that signers necessarily apply Author Signatures
whenever they're signing for their domain, or they need to have use
appropriately restricted keys whenever they don't want to do that.

I don't see the advantage of doing it this way, and a couple of
disadvantages.

-Jim

Douglas Otis wrote:
> Signature compliance changes when a From domain's SSP indicates "strict".
>
> NOTE WELL: This list operates according
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Jan 2008 12:30:43 -0800

On Jan 10, 2008, at 3:58 PM, Jim Fenton wrote:

> This is mixing together two issues.  The question of what  
> constitutes an Originator (now Author) Signature applies to all SSP  
> practices because it's the basis for deciding whether to look up SSP  
> at all.  For that reason, I'd suggest leaving "strict" out of it.

Jim,

Your statement appears to be in error.  Please review the "all" and  
"strict" definitions:

---
The SSP definition for "all":

All mail from the domain is signed; unsigned email MUST be
considered Suspicious. [Others might modify and sign.]

The SSP definition for "strict":

All mail from the domain is signed; messages lacking a valid
Originator Signature MUST be considered Suspicious. [Others
are not expected to modify and sign.]
---

The additional requirement of a valid "first author" signature for  
"strict" makes "all" significantly different.  The "first author"  
signature definition currently stipulates that a signature is not  
compliant unless on-behalf-of the "first author", even when signed by  
an unrestricted key of the "first author's" domain.  IMHO, this  
creates an unnecessary and unreasonable exclusion for unrestricted keys.

> So the question then is whether the local-part of i= should be part  
> of the match against the From address to determine whether it's an  
> Author Signature.  If I understand your proposal, you're suggesting  
> that we only match the local-part if the g= of the key is  
> constrained (the key isn't valid for all addresses in the domain).   
> If this were done, the input to SSP would be not just the message  
> itself, the SSP record, and information about validity of signatures  
> in the message.  It would also be necessary to have information from  
> the selector records about the g= value of each.

No.  As currently defined by SSP, signatures are not "strict"  
complaint when not seen as on-behalf-of the "first author".  However,  
as currently defined by SSP, a restricted key is SSP "all" compliant  
regardless of who the signature is on-behalf-of provided the signature  
is valid.  This means the compliance state must be currently tracked,  
where the recommended change does not alter the need for this  
tracking.  There is RFC 4871 valid, and SSP "all" and "strict"  
compliant.  Any verification process must keep track of a signature  
being both valid and SSP "strict" and "all" compliant.  The change  
being recommended is to minimize the difference between being valid  
and "strict" compliant.  The change reduces the requirement for  
unrestricted key being SSP "strict" complaint where the "on-behalf-of"  
would not matter.  Only restricted keys must be seen as on-behalf-of  
the "first author".

> In all other respects, the selector data is only used [for]  
> verifying the signature itself.

I am unsure what you mean by selector, but a selector does not appear  
to play any role here.  I assume you are concerned with passing  
results from the verification process.  The verification process would  
need to signal the detection of a restricted key in addition to  
validity.

When deciding whether to request an SSP policy, a verifier would first  
determine whether the message contains an SSP "strict" complaint  
signature per the revised definition.  This definition only excludes  
"first author" domain signatures that are using a restricted key not  
on-behalf-of the "first author".  When a SSP "strict" compliant  
signature is determined, there would not be any need to query for SSP,  
as the message would meet the definition of both "strict" and "all"  
compliance.

When the signatures of the "first author" domain are using a  
restricted key and are not on-behalf-of the "first author", compliance  
therefore depends upon finding either "all" or "unknown" SSP  
assertions.  Perhaps RFC 4871 should have declared any restricted key  
not on-behalf-of the first author to be invalid.  A restriction on  
what headers a restricted key is allowed to sign would allow combining  
together both "valid" and "restricted" results into a single state.   
However, AFAIK, restricted signatures are valid for any header and are  
compliant with an "all" policy assertion.

> Signers that have a key that is unconstrained always have the option  
> to sign with an empty local-part.  Basing the decision on the  
> presence of g= in the key means that signers necessarily apply  
> Author Signatures whenever they're signing for their domain, or they  
> need to have use appropriately restricted keys whenever they don't  
> want to do that.

There is no justification for having an SSP "strict" assertion require  
the use of ambiguous signatures, or signatures falsely identifying who  
the signature is on-behalf-of!  Your approach greatly reduces the  
utility of the i= parameter.  It would also represent an unlikely  
application of RFC 4871.   As currently SSP assertions are currently  
defined, compliance MUST BE tracked separately from that of a  
signature being valid.

> I don't see the advantage of doing it this way, and a couple of  

I hold the opposite view.  I don't see any advantage using your  
definition other than being able to combine together the "valid"  
result with that of a "restricted" key.

Your approach of combining valid with restricted:

1) limits the utility of the i= parameter

2) creates astonishing corner cases

3) increases the likelihood of needing to discover SSP records

4) distorts who a DKIM signature can be on-behalf-of

Our different perspectives appear to result from combining RFC 4871  
valid, and SSP "all" or "strict" compliant into a single state.  These  
truly represent different states.  Combining "valid" and "compliant"  
is already wrong per the current SSP definitions for "all".

-Doug