[ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats

[Hector Santos]

Dave, I agree with all your comments here. +1, +1, +1, +1000, +1.

However, two comments:

1) I find it hard to believe, well, shocking, that we have gone around 
in circles just to come back to what the DKIM specification always 
was. It was always about the domain. We used terms as the originating 
domain.  The only tie-in to the local part was the From: header 
binding in the hash.  Then the word game began.......

2) I still have a concern with what I feel is a mindset that middle 
ware (namely mailing list server) can do what they please.  I think 
there are key people here that honestly believe this ASDP is all for 
nothing - waste of time because it does not jive well with the mailing 
list.  I always feel ADSP was too watered down by removing the the 
domain authorization to explicit expose a 3rd party signing allowance. 
   IMO, that is the reason we had this issue with d= and i=, and 
semantics of who signs what.

I think the often repeated point that domains need to take 
responsibility about how they will begin to use DKIM, especially those 
that want to use policies, is important. It is their problem. Yet by 
the same token. this also means the mailing list server needs to be 
more careful about signing mail as well.

For example, for our mail list server, there are three key software 
change considerations for DKIM + POLICY:

    - subscription, adding to a packages existing subscription
      confirmation a subscribing domain ADSP check for DKIM=ALL
      and DISCARDABLE policies.  The software SHOULD reject this
      subscriptions to protect the domain.

    - Periodic scanning the accounts to send notifications about
      ADSP protected domains that exist in the database.

    - Provide per member options such as:

         [_] Please don't sign my mail

The last one are for people who do not, nor wish to participate in 
supporting DKIM for whatever reason they might have.  I can forsee 
issues just like I have now with your list server "blinding" signing 
my mail as a 3rd party.  Out of laziness I have not unsubscribed yet 
but I should do so soon and just use my junk gmail.com account.

This is another reason why I think the lost of the "I NEVER SIGN" 
policy was a negative direction.  Until people are ready to sign, some 
domains will find it useful to add some reason that tells the 
receivers "Look, don't expect any signature from us, so if you see 
one, discard it."   Someone said, I think it was Eric, "Just add a 
NULL public key."   But when I repeated that here a few months ago, 
others said say "that won't work"  :-(

Other than that, +1.


Dave CROCKER wrote:
> 
> Jim Fenton wrote:
>>      The correct test case is:
>>
>> >From someone at foo.example
>> Valid signature from ietf-examples at foo.example
> ...
>> At this point, the mailing list manager would normally sign the
>> message.  Let's examine this with the i= and d= choices:
>>
>> Using i= as the basis for Author Signature, the list can sign the
>> message, and the eventual verifier/assessor that does an ADSP check will
>> see that it (still) lacks an Author Signature since
>> ietf-examples at foo.example does not match someone at foo.example.
>>
>> Using d= as the basis for Author Signature, if the list signs the
>> message, an eventual verifier/assessor will erroneously see that
>> signature as an Author Signature, and therefore might not give the
>> message the desired treatment.  
> 
> 
> I think there are two sources of confusion for this round of ADSP discussion.
> 
> The first is that the term "Author Signature" encourages one to think that DKIM 
> is used to sign with the full author email address, rather than with the 
> /domain/ of the author's address.  We fixed that error in the name of the 
> document, but forgot to carry it through to the details of the spec.
> 
> DKIM is about domains, not email addresses.  And that's all ADSP should be. 
> Using i= encourages this cofusion.  Using "Author Signature" rather than "Author 
> Domain Signature" also encourages it.
> 
> The second is whether a receiver should be asked to enforce controls for usage 
> by folks /within/ the originating domain's span of control.  It's one thing to 
> worry about unauthorized use by someone /outside/ of the owning domain's 
> control, but quite another to ask a receiving system to help keep the owning 
> domain's own house clean.
> 
> If the domain owner cannot exert enough administrative control, to keep 
> signatures for mailing lists separate from signatures for authors, then that's 
> the owner's problem.  It shouldn't be the receivers.
> 
> The same applies for one author vs. another, within the same domain.
> 
> 
> The specification and semantics of ADSP get simpler, cleaner and properly 
> scoped, when d= is used.  Using i= really does invite a complex of issues that 
> should be outside the scope of DKIM and ADSP.
> 
> Use d=.
> 
> d/
> 
> ps.  That includes dropping the "ADSP is incompatible" note.
> 


-- 
Sincerely

Hector Santos
http://www.santronics.com