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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
