Subject: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting

From: Hector Santos <[email-masked]>
Date: Tue, 03 May 2011 09:28:33 -0400

RFC5617 has for this tag value:

    dkim=   Outbound Signing Practices for the domain (plain-text;
            REQUIRED).  Possible values are as follows:

            unknown   The domain might sign some or all email.

For my A-R reporting if there an explicit DKIM=UNKNOWN record, I took 
this declaration to mean the domain only allows it to sign sometimes 
and no one else.
There is no failure handling semantics unlike DKIM=DISCARDABLE, so no 
verifier action is done other than A-R record it.

For example, this is such a reporting for a list message posted here 
by Alessandro with its tana.it domain.

Authentication-Results: dkim.winserver.com;
  dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
  adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org 
(unauthorized signer);

The "(unauthorized signer)" was added because it was an explicit 
DKIM=UKKNOWN DNS record declaration.

If there was no ADSP record, the adsp= info would look like this:

  adsp=none author.d=tana.it signer.d=mipassoc.org;

Would that be a reasonable valid A-R reporting for ADSP based on my 
interpretation of explicit vs implicit DKIM=UNKNOWN setting?

Of course, it should been labeled as DKIM=OPTIONAL because if someone 
went to extent to declare a record, it wouldn't be unknown what he 
intended.

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 May 2011 07:00:51 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Tuesday, May 03, 2011 6:29 AM
> To: [email-masked]
> Subject: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
> 

That's not what RFC5617 says.

> DKIM=UKKNOWN DNS record declaration.

Reporting a "fail" against "dkim=unknown" is technically impossible.  You should use "unknown".  See Section 5.4.

Also, it should be "dkim-adsp", not "adsp".  See Section 5.3.

>   adsp=none author.d=tana.it signer.d=mipassoc.org;

"none" doesn't appear in the registry.

---

From: Hector Santos <[email-masked]>
Date: Tue, 03 May 2011 10:58:51 -0400

> That's not what RFC5617 says.

    Meaning:  No valid Author Domain Signature was found on the message
              and the published ADSP was "unknown".

Can't that be read as meaning a non-Author Domain Signature was not 
expected.

> Reporting a "fail" against "dkim=unknown" is technically impossible.  

I don't quite read it that way Murry.  But it says No Author Domain 
Signature, it would be a failed. See below why I used "adsp=" instead.

> You should use "unknown".  See Section 5.4.
> 

I am also reporting ADSP/ATPS/ASL reporting and wanted to fold it into 
one line. The "adsp=" tag is for handler PASS|FAIL|NONE status for our 
internal MAIL API consumption only. I needed a different simpler 
namespace to not step over the two line dkim-adsp, dkim-atps.

   adsp=<HANDLER status> [policy=<explicit-dkim=value>] ....

Anyway. My Reading is:

    No DNS record  - no consideration for ADSP whatsoever. No (NONE)
                     assumptions can be made, so you can't default
                     to an "UNKNOWN" because it was known to the
                     author and verifier - it wasn't defined (NONE)

    DKIM=UNKNOWN   - it describes it as an optional expectation
                     and its defines it as Author Domain, not
                     just any signature.

To me, there is diagnostic value between a real no signature (NONE) 
and an invalid one (FAIL). I don't wish to combine those as UNKNOWN. 
In short the combinations of inputs and outputs allows for all states 
to exist.

Note, these are all part of the semantics ambiguities discussed in the 
past regarding ADSP.  I hope we can fix it.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 May 2011 13:29:22 +0200

> interpretation of explicit vs implicit DKIM=UNKNOWN setting?

I don't think so.  The only difference between setting "unsigned" and letting
it be derived by default should be the ability to control the expiration of
such value.

As for ATPS, I will happily mention mipassoc.org as authorized signer, and
I'll possibly authorize more domains, but then I'll also forget some.  That's
what happened when I enabled ADSP promising to myself to whitelist each and
every MLM, and failing to keep it.  IMHO, MLMs should tell authors' servers
about subscriptions, as that would solve a number of problems.  Until they
continue not doing that, this particular problem remains among the unsolved ones.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 08:56:17 -0400

Alessandro Vesely wrote:

> I don't think so.  The only difference between setting "unsigned" 
> and letting it be derived by default should be the ability to 
> control the expiration of such value.

Can you rephrase this so I can better understand your thinking?

I am merely thinking of terms of "intent."  With no ADSP record, then 
I view that as a conscience operational decision to allow any signer 
to exist (for your messages).

But if have an explicit ADSP record, that is a conscience operational 
decision to assert a policy declaration, one that comes with an author 
domain expectation (See RFC5017) for a valid signing practice.  When 
the policy is violated, it is very important to know that in order to 
get a payoff value.

I would like to point out there is a long term philosophical mindset 
conflict in regards to what is expected in receiver local policies:

  Accept all, Let Users decide, the DMA (Marketers) Cat's Meow.

vs

  Deterministically Filter all the bad first, controlling receiver
  (and thus users) abuse.

So depending on what side one is on or lean towards, the design 
considerations vary greatly.

So only as an rhetorical example, what was tana.it intent by declaring 
DKIM=UNKNOWN?

Per ADSP section 4.2.1 and 5.4:

    Meaning:  No valid Author Domain Signature was found on
              the message and the published ADSP was "unknown".

To me that means when a message is signed, it MUST be a valid 1st 
party.  When only a 3rd party signature is found, it is a policy 
violation.

But thus we have the root of the conflict:

See RFC5017, section 5.4 item #10.

  10. SSP MUST NOT provide a mechanism that impugns the existence of
      non-first party signatures in a message.  A corollary of this
      requirement is that the protocol MUST NOT link practices of first
      party signers with the practices of third party signers.

       INFORMATIVE NOTE: the main thrust of this requirement is that
       practices should only be published for that which the publisher
       has control, and should not meddle in what is ultimately the
       local policy of the receiver.

This was a very controversial item and you can see the sensitivity of 
it by the words used to mandate a MUST NOT!

On the way one hand, it wants receivers to mind their own bee's wax in 
regard to 3rd party signers but excluded the idea that receivers may 
want to honor author policies as part of their local policies.  Item 
#10 was the central conflict that created ADSP in an attempt to get 
receivers to ignore the existence of 3rd party signatures and just use 
ADSP to look for the author domain non-signed messages.  If the 3rd 
party signature exist, ignore it.  Thats a engineering flaw when you 
have explicit policy declarations telling receivers what is expected.

> As for ATPS, I will happily mention mipassoc.org as 
> authorized signer, and I'll possibly authorize more domains, 
> but then I'll also forget some.  

Right, but does that means others would not a have definitive 
operational understanding of how their mail will be signed or expected 
to be signed?  I think receivers can only work with DKIM on a basic 
idea to give the domain the benefit of the doubt.  If you declare a 
policy, that helps alot. Otherwise, the domain really doesn't care, 
but the receiver will still care when it becomes abusive.

> That's what happened when I enabled ADSP promising to myself 
> to whitelist each and every MLM, and failing to keep it.  IMHO, 
> MLMs should tell authors' servers about subscriptions, as that 
> would solve a number of problems.  Until they continue not 
> doing that, this particular problem remains among the unsolved ones.

+1.  I think we can correct ADSP if it semantics can covers the ideas:

ALWAYS SIGNED:

     By ME
     By any signer
     By MLM signer

ALWAYS SIGNED with Authorization using Extensions

     By ME
     By any Authorized signer
     By any Authorized MLM signer

I am not sure if we need to distinguish list signers but if we want to 
separate private vs public mail streams, maybe it can help.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 May 2011 18:41:37 +0200

On 04.05.2011 14:56, Hector Santos wrote:
> Alessandro Vesely wrote:
>> The only difference between setting "unsigned" and letting it be derived
>> by default should be the ability to control the expiration of such
>> value.
> 

ATPS wasn't visible when I set that record.  The only reason I put it there
was to state a decent TTL, which makes sense since the design of the DNS is
such that replying "not found" never costs less than directly stating that
it will stay unknown at least for the whole day.

> I am merely thinking of terms of "intent."  [...]
> 

Hm... I'm not sure how layer logic applies to that reasoning.  A default is
a value; discriminating whether it was explicitly given or assumed resembles
Terrell's ternary logic, holding that a bit has three values
http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 May 2011 16:43:20 -0400

> Can't that be read as meaning a non-Author Domain Signature was not

No, not at all.  I can't think of any interpretation of that sentence
that would give that meaning.

"No valid Author Domain Signature was found" says nothing about
anything else that might or might not have been found.

"If it rains, then I won't play baseball," says nothing about what
I'll do if it doesn't rain.

Barry, as participant

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 May 2011 21:31:15 -0400

Barry Leiba wrote:
>> � �Meaning: �No valid Author Domain Signature was found on the message
>> � � � � � � �and the published ADSP was "unknown".
>>
>> expected?

This is part of the semantics clarification we seek.  You are probably 
catching up, but the text descriptions for DKIM=UNKNOWN are found in 
ADSP Section 4.2.1 and 5.4:

Think of the software:

First, No ADSP record is found.

In this case, there is absolutely no policy semantics regarding DKIM 
the verifier can make for the author domain.  No sig, double, triple, 
mixed 1st, 3rd, some valid, some broken, whatever, the verifier can 
not make any ADSP interpretation other than  dkim-adsp=none.

But now we have an explicit DKIM=UNKNOWN;

The semantic and also part of the WG conflicts is the absence of a 
valid Author Domain signature and includes the presence of a valid 3rd 
party signature.

In other words, should the verifier?

   #1 - ignore signatures where SDID != ODID, and
   #2 - only look for signatures where SDID == ODID

The problem Barry, and this was a long term issue with ADSP, is that 
it lacks an explicit semantic or definition where it says:

     mail can be signed by anyone

or

     ignore mail that have 3rd party signatures

This conflict begins in RFC5017 (Requirements for Signing Practice) in 
most debated item in section 5.3, Item #10:

   5.3. Practice and Expectation Requirements

         Refs: Deployment Consideration, Section 4.3.

Base on this, its implies to me we should ignore 3rd party signatures, 
but that is conflicts with ADSP and even the fundamental idea behind 
RFC5017 - check for author  policies and policy violations.

So I can understand that if there are no explicit record, then the 
receiver can not make any presumptions about the signatures in the 
message.  But if there is a record, then its negates what item 10# is 
saying for the verifier with a local policy to support ADSP to mind 
its bee's wax with the presence of a non-first party signature.

Do you see the conflict?

Just consider when an explicit ADSP record is found with:

     DKIM=DISCARDABLE
     DKIM=ALL

Does these also come an item #10 ignore 3rd party signature concept 
even with the receiver is willing to honor ADSP and author domain 
policies?