Re: [dmarc-ietf] DMARC ATPS Interop Note

[Hector Santos <[e-mail]>]

Murray, a clarification about DSAP.

Of late, I've been using the term DSAP as a general methodology for a 
complete DKIM Signature Authorization Protocol.  DSAP, TPA, ATPS are 
all the basic ideas.  We need a generic term since there are many with 
all the same basic functional principles, but in different syntax 
languages.

However, for the record, there was a 2006 DSAP I-D proposal

    https://tools.ietf.org/html/draft-santos-dkim-dsap-00

that I believe you referred to.  I want to make a clarification above it.

In general, DSAP covered the same policy ideas as with SSP using a 
different language.  SSP covered these polices:

    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

DSAP was more about the protocol methodology covering all the possible 
signature boundary conditions in the Protocol State Machine for two 
signatures; combinations of 1st party with a 3rd party, including the 
lack of the signatures. It described this using two tags:

    4.2.  DSAP Tags: op=<signing-policy>; 3p=<signing-policy>;

    From the viewpoint of the verifier, when a message is received, there
    are two basic pieces of signature information to be of interest when
    analyzing the transaction:

    o  Original Party Signatures (OP)

       *  never expected
       *  always expected
       *  optional

    o  3rd Party Signatures (3P)

       *  never expected
       *  always expected
       *  optional

    When the two signature types are combined, the possible policies are
    listed in this following table:

     +=================================================================+
     | op=         | 3p=        | Domain Policy Semantics              |
     |=================================================================|
     | empty       | empty      | No mail expected                     |
     |-----------------------------------------------------------------|
     | never       | never      | No signing expected                  |
     | never       | always     | Only 3P signing expected             |
     | never       | optional   | Only 3P signing optional             |
     |-----------------------------------------------------------------|
     | always      | never      | OP signature expected                |
     | always      | always     | Both parties expected                |
     | always      | optional   | OP expected, 3P may sign             |
     |-----------------------------------------------------------------|
     | optional    | never      | Only OP signing expected             |
     | optional    | always     | OP expected, 3P expected             |
     | optional    | optional   | Both parties may sign.               |
     +-----------------------------------------------------------------+

                   Figure 4: DSAP Message Signing Policies


But for 3rd party authorization, without a complete satisfactory DNS 
way to do this and a desire to not do another DNS call, a minimal 
smaller scale method was proposed using a "3pl=" record tag:

    4.3.  DSAP Tag; 3pl=<dom-list>;

    The 3pl= is an optional tag that defines a list of 3rd party domains
    who are allowed to DKIM sign the message as a 3rd party signer.  This
    tag is ignored unless 3rd party signing policy is expected or
    optional (3p=always or 3p=optional).

    <dom-list> is a comma delimited list of domain names.

    Example:

    3pl=isp.com,outsource.com,mailinglist.com;


When Doug introduced the TPA hashing idea, it fit the need for larger 
scale needs but it was written too complex.  When you improved the TPA 
idea with ATPS using simple TRUE/FALSE (record exist) semantics and 
also using the same TPA hashing ideas, I implemented ATPS instead.  It 
was just simpler and easier to code, test and explore.

So my implementation of the DKIM policy experiment and exploration was 
with the small scale "3pl" tag now called "asl" for Allowed Signer 
List and the ATPS support for the larger scale DNS lookup:

     [atps=y;] [asl=resigner-domains;]

That was made off ADSP and now off the DMARC record.

It works. DMARC extensions are supported at implementations from a 
parsing standpoint. They won't abort. And for ASL, ATPS supported 
receivers, it works.  As long as you can manage your DNS records, it 
works fine.

I think perhaps what we need to do is step back and think about what 
DMARC should be doing as far as DMARC extension tags to make this all 
optional and available.

I like the SAM idea ("Signer Authorization Method"), Doug called it 
Specific Advisory Method, so a tag that defines the method a signer 
may wish to authorize and I think we have two basic ideas:

    sam=atps      dns lookup (default)
    sam=dsfs      dual signature

I say atps should be default because its the simplest to implement 
without changing dkim engines.

I don't think you should push for Dual Sign method only.

--
HLS

On 5/11/2015 1:08 AM, Murray S. Kucherawy wrote:
> On Sun, May 10, 2015 at 4:37 PM, Douglas Otis <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     ATPS included an onerous task for any third-party service
>     likely used on a gratis basis. Each third-party was expected
>     to learn specific hash algorithms of each From domain.  A
>     difficult process on top of changing their structure of DKIM
>     signatures repeated tens of thousands of times for each
>     different first party domain. In addition, reputations based
>     on the third-party relationship could not be leveraged
>     because of the optional hashing.
>
>
> I continue to find this repeated claim specious at best.
>
> Section 7 of ATPS describes the structure of the experiment and
> invites feedback from anyone who tries it.  Apart from Hector's recent
> declaration and one hobby user of my open source implementation that
> enabled it, there has been no feedback from the community at large
> that anyone has tried it or any variant of it.
>
> Given the pain point that a widely adopted authorized third-party
> signatures scheme (in general, not just RFC6541) would solve, one
> would think we'd have heard something in this regard in the last three
> years.  Nothing beyond what I just mentioned has materialized.
>
> If you intend to claim that this is because of specific aspects in
> RFC6541 of how the DNS records are generated, I suggest you consider
> that even small operators don't have a problem computing hashes or
> populating DNS zones, because computers are good at automating
> things.  Even if they did see those things as burdens, such operators
> tend to be the sort to provide that kind of feedback even about a
> protocol they ultimately can't use.  Seriously, what person in the
> email space that you've met in the last N years would not take an
> opportunity to provide feedback, constructive or otherwise?  We are a
> rather opinionated bunch and love the sounds of our own voices.
> Someone would've said something by now.  But it hasn't happened.
>
> TPA has existed even longer than ATPS has, and it has enjoyed
> similarly goose-egg-shaped amounts of adoption.  DSAP was around even
> before that, and the story is the same.  What they all have in common
> is that they are not even close to something that serious operators
> would be willing to try.  They are plagued by -- you guessed it -- the
> registration problem.
>
> Absent a change in that posture by the community at large, this is
> manifestly a dead end, and we really, seriously, need to stop burning
> any more of our precious cycles on it.
>
> -MSK
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 
HLS