ietf-dkim
[Top] [All Lists]

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

2007-12-12 16:02:40
Doug,

I would like to know one thing:

   When does a signer expect when his signature to be broken?

or

   When is it reasonable for a signer to believe his signature
   can be broken? and if so, what does he expects to happen?

I mean, after all, this is all about mail integrity and an attempt at non-repudiation. It gets to a point where if a domain is going to begin to digitally sign its mail, then there is a reasonable expectation that it will be non-repudiated.

By definition, non-repudiation occurs when all participants agree that something is true.

So given our current email infrastructure what steps are taken to ensure full or partial non-repudiation?

There has to be some statements of facts, and in my opinion, a domain signing his mail under a set of conditions he holds to be true, can only non-repudiated if the receiver can hold him to these expected true conditions.

If the domain says "I'm the exclusive signer," than nothing should repudiate that true condition of exclusivity.

If the domain expects a different set of relaxed conditions that can be repudiated, then he really shouldn't be signing his mail or have his signed by others and still expect verifiers to waste its time with it trying to reach an impossible state of non-repudiation.

It can't be both ways Doug. Something is got to give here.

--
Hector Santos, CTO
http://www.santronics.com


Douglas Otis wrote:

On Dec 12, 2007, at 9:42 AM, Jim Fenton wrote:

If their web form didn't block the use of example.com as a From address, the message would be non-Suspicious (I think that's what you mean by "compliant" in this context), which would violate the likely intent of the publication of SSP "all". They could deal with this in several ways:

- Prohibit example.com from being used in the web form
- Sign using a different domain or a subdomain, e.g.,
i=(_at_)articles(_dot_)example(_dot_)com

In this case, "articles.example.com" will obscure which header the signature had been added "on-behalf-of". If the signing domain was also "articles.example.com", this would be a third-party signature and might make the message somewhat questionable. Mailing-list may sign "on-behalf-of" the List-ID header, where any email-address might be allowed in the From header (common for many mailing lists). 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". The domain may not care whether an ambiguous "on-behalf-of" causes confusion. The email-address could be that of some innocuous role that is never used for other messages, where the Subject line also clearly indicates that the message is from a list.

- If comparison of the local-part of the address continues in the draft, sign with a specific address, e.g., i=articles(_at_)example(_dot_)com, and have the web form prohibit that specific address


A domain can be completely compliant with an "all" assertion _without_ prohibiting specific email-address from being signed! A mailing-list is often unable to authenticate identities, even those signed by DKIM! DKIM is _prohibited_ in the charter from asserting identities, nor would identity authentication represent a safe assumption. Defaults allowed for the i= parameter permits an "on-behalf-of" header to remain ambiguous. While some domains may wish to prevent intra-domain spoofing by employing email-address constraints, such constraints are not typically, nor is this defined for use with DKIM.

When a message contains a header where the From contains an email-address within the signing domain, acceptance depends upon internal signing domain policies. The "all" assertion DOES NOT imply an identity associated with an email-addresses has been authenticated! Such an assertion violates DKIM's charter, where DKIM is not sufficiently suited for such use. DKIM lacks a means to distribute per-user keys, lacks any mandate regarding identity authentication, mechanisms to restrict email-address use, etc. Procedures and policies to restrict the use of email-addresses, and whether messages are permitted to include From headers containing other email-addresses within the domain is completely a matter of internal policy. This internal policy has nothing to do with an "all" assertion. The "all" assertion only indicates to receivers, they can expect all messages originating from this domain to have been signed.

Ensuring who can use an email-address is an entirely different problem unrelated to "all" or "strict" policy assertions. Attempting to extend DKIM in this manner appears to violate the charter as well.

-Doug



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




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