Re: [ietf-dkim] Re: Issue #1524: Signature semantics

On Dec 12, 2007, at 2:48 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > The mailing-list may wish to exclude the list-id email-address from  
> > being allowed within the From header to prevent confusion as to  
> > which header the message was signed "on-behalf-of".
> A syntactically valid List-ID doesn't have the form of an email  
> address or Message-Id, no "@".
Agreed.  Nevertheless, i=<list-id>@<d=domain> could still be used.  A  
valid signature does not need to match local-parts with the i=  
parameter.  Only the domain component must be at or within the signing  
domain.
> > While some domains may wish to prevent intra-domain spoofing by  
> > employing email-address constraints, such constraints are not  
> > typical, nor is this defined for use with DKIM.
> RFC 4409 6.1 and 8.1 won't help with "first author" constructs, and  
> 8.1 arguably does not yet support PRA.  But it's not an untypical  
> request, compare op=auth for SPF proposed by Scott.
DKIM's concept of "on-behalf-of" may offer an advantage when extending  
the MAILFROM email-address to other headers.  The WG should ensure  
nothing interferes with "on-behalf-of" semantics.  Current SSP  
definitions impose an unwarranted constraint on the i= parameter when  
"strict" is asserted.  Currently the From header MUST BE indicated as  
being signed "on-behalf-of".  This is wrong.  Just the domain of the  
From email-address MUST BE within the domain of the d= parameter.   
The only exception should be for g= restricted keys.
> > The "all" assertion DOES NOT imply an identity associated with an  
> > email-addresses has been authenticated!
> It implies whatever the SSP spec. says.  If it says something in the  
> direction of op=auth it has to state what signers are supposed to do  
> to enforce it.
The SSP specification could indicate identities associated with email- 
addresses signed "on-behalf-of" MUST BE authenticated.  Neither SSP  
nor the DKIM base says this anywhere.  Nor is this level of  
authentication normally supported.
> > Such an assertion violates DKIM's charter, where DKIM is not  
> > sufficiently suited for such use.
> It mentions the issue as out of scope, yes, but I'm not sure if that  
> also limits what an SSP can state.
DKIM can not safely offer strong identifiers without extensive, and  
currently non-existent, specifications.  Perhaps at some point an  
assertion could be defined that specifically indicates what has been  
authenticated and how.  For now, a temporal opaque identifier seems  
less problematic from both a privacy and system compatibility  
perspective.
> IMO intra-domain spoofing isn't an interesting problem, but if an  
> MSA offers its sending and signing services to more than one domain  
> then excluding "cross-user forgery" between them is relevant.
A mailing list should be able to assert "strict" and sign any email- 
address in the From header with an email-address from any other  
domain.  Only domains submitting messages to this list might indicate  
this is a problem with their "strict" assertion.  This issue can be  
resolved using TPA-SSP assertions.  When a domain does not assert  
"strict", cross domain forgery can not be reliably detected.  Few  
issues should prevent a domain having trouble with cross-domain  
forgery from making this assertion.  However, intra-domain forgery  
must be handled internally.
DKIM should not attempt to dictate that email-addresses must only be  
used by their valid owners.  That would be a matter for the signing  
domain to decide.  Lacking a means to assert this authentication is  
being done is a secondary issue.  When DKIM is considered unsuitable  
for providing strong identities, it then becomes important _not_ to be  
able to make an assertion that identities owning a particular email- 
address have been authenticated.
> RFC 4409 has options for SPF (6.1) and a part of PRA (8.1). Or is  
> that beside the point ?  Actually a service provider offering  
> sending and signing for more than one domain has to do something  
> about "cross-user forgery" for DKIM, no matter what SSP specifies.
The provider MUST use the correct signing domain.  The rest sorts  
itself (perhaps along with a check of foreign domain's SSP records).
The TPA-SSP permits a similar MailFrom assertion without using an IP  
address list.
> > The "all" assertion only indicates to receivers, they can expect  
> > all messages originating from this domain to have been signed.
> Kind of tough if they get a message signed by the MSA, but actually  
> submitted by another domain (ab)using this MSA.  :-(
The verifier must make an exception for third-party signatures.  Any  
third-party signatures found abusing other domains are likely to be  
dropped from such a list.  Reputation is likely where the correct  
practices become more important than meeting SSP specifications.   
Perhaps signers should check for "strict" assertions.
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html