[ietf-dkim] brand protection, was Is anyone using ADSP?

[Ian Eiloart]

>> authentication-results header for the original signature, if that header
>> were signed, and the list domain had a reasonable reputation.
>
> The problem with rejects is that it can cause a MLS to initiate sending
> subscriber removal notification messages. For example, the mipassoc.org
> list server will send you a "Last Warning" removal notification if your
> hosting server rejected a list message X number of times.  That was the
> key issue and reason I posted the concern; we now have concrete proof of
> an interoperability problem caused by the intermediary intentionally
> ignoring RFC 5671 restrictive policies. IOWs, we now have user victims
> who with no fault of their own are now subject to removal threats due to
> MLS signer *neglectfully* not filtering this ADSP domains.

I understand that issue. That's why receivers should NOT reject messages 
with broken DKIM records when they come from a trusted mailing list. They 
should assess the list, not the original sender. That's sensible, because 
list recipients usually know more about the list than they do about all the 
people subscribed to the list.


> In regards to the **pass, IMV, I am not concern about how we can accept
> 3rd party signatures.  There are ideas for this.  But its probably better
> to use another policy and not DKIM=ALL unless the specs were changed to
> provide those semantics. But as it stands, it clearly does not say that
> 3rd party signatures are implied in shape or form.  I see no proof or
> wordings whatsoever that DKIM=ALL allows 3rd party signers.

It's there. Section 1 of rfc5617  "The basic requirements for ADSP are 
given in [RFC5016].  This
   document refers extensively to [RFC4871] and assumes the reader is
   familiar with it."

rfc4817 is DKIM, rfc5016 is "Requirements for a DomainKeys Identified Mail 
(DKIM) Signing Practices Protocol"

rfc5016 section 3.1 gives a use case that is implemented with the tag 
"dkim=all": "Domain Alice provides information that it signs all outgoing 
mail, but places no expectation on whether it will arrive with an intact 
first party signature. Domain Bob could use this information to bias its 
filters to examine the message with some suspicion."

The interpretation is left to the recipient. In my view, if the recipient 
sees no good reason that there's no intact first party signature, the mail 
could be rejected but not discarded, thus allowing senders to be alerted to 
false positives. If the receiver sees a good reason that a signature is 
broken, they should accept it. A good reason would be that the message has 
been forwarded by a mailing list (DKIM or SPF validated) that the recipient 
is subscribed to.

Also, read section 5.3 and note the difference between requirement 3 and 
requirement 4. I believe that 3 is implemented with dkim=all and 4. is 
implemeted with dkim=discardable.

And, note 4.3: "...remailers that break DKIM first party
   signatures can be potentially assessed by the receiver based on the
   receiver's opinion of the signing domains that actually survived."

> The fact that
> it is open-ended with no explicit action semantics does not mean 3rd
> party signatures are allowed. If that is the desire then IMV it needs to
> be updated to say so.  Otherwise we have what we have now - confusing.
> With all due respect to Mr. Deutschmann, Mr. Levine wrote RFC 5617. Not
> Mr. Thomas. Mr. Levine's interpretation is what counts.
>

And, Mr Levine appears to agree with Mr Thomas, but be concerned about 
misinterpretations. I agree that the implementation guide needs to be very 
explicit about this scenario, and it might even be useful for the ADSP RFC 
to be updated to provide guidance here.


-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/