Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Hector Santos <[e-mail]>]

On 1/19/2021 9:02 AM, Todd Herr wrote:>
> Other concerns were raised about privacy and security issues that
> might be inherent in and unique to adding this kind of functionality,
> issues that may not have been fully discussed or understood by the
> community over the years. There was also a question about whether or
> not this is something that people are asking for.

Reporting concepts were in the each DKIM Policy proposal (SSP, DSAP, 
ADSP) -- a "-r" tag option to send reports. The main concerns were 
unsolicited report abuse.   The DSAP proposal (my own) recognize it 
could be optional so it provided:

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

    4.5.  DSAP Tag: r=<abuse-address>

    This tag is optional.  If not defined, the default is no abuse-
    address is available.

    <abuse-address> is either the user-part or a FQDN email address to
    optional send abuse reports.

    Examples:
       r=abuse
       r=[e-mail]

    If only the user-part is defined, then the full address is
    established by using the originating address domain.

    DKIM verifiers have the option to honor or not honor this reporting
    address.  DKIM signers MUST be aware this reporting address may not
    be utilized by verifiers.

    Verifiers should be aware this reporting address can be a source of
    an report attack vector (Section 7.4).  One possible implementation
    considerations would to limit the report to one report only and to
    track the reception and/or response of the reporting.


but the Section 7.4 discussion was TBD.


>
> Hatless, it seems to me that the safest implementation of this
> feature, presuming the security and privacy concerns can be addressed
> to the satisfaction of those who raised them, would be to add a new
> tag, as John has proposed, so as to minimize interoperability issues.
> I say "minimize", rather than "avoid", simply because while RFC 7489
> says "Unknown tags MUST be ignored.", I don't believe we can say with
> 100% certainty that all implementations of DMARC policy record parsing
> in the known world (both by report generators and third parties who
> advise domains on how to publish DMARC records), implementations that
> work now, won't "break" if a new tag is introduced. Of course, that'd
> be their problem, not ours, because they weren't following the
> existing rules.

We can not continue to design Internet protocols without upward design 
considerations. This is part of the forward and backward compatibility 
design concepts.  Any problem would be a known tag with new 
functionality than originally expected. Sure, we can't say it will not 
happen, but its going to be a very low percentage, if any.  They have 
to fix it.

> As editor, I seek guidance from the working group on how to proceed here.

I am for a URI protocol method as part of the current tag rather than 
a new a separate tag.

However, in principle, I don't see any issue with adding new tags, in 
fact, I am still here on the basis extended protocols will emerged 
once the base protocol is completed.  ATPS will be available to 
piggyback off the DMARC record as it did off ADSP.  The ATPS protocol 
adds "atps=y" tag to the DMARC record.  We have never received reports 
of issues related to extended tags.

There is a also a small scale version called ASL (Authorized Signer 
List) tag which defines a few domains authorized as resigners; for 
example:

asl=example1.com, example2.com, ietf.org, gmail.com

If you believe that adding a new tag is going to be a problem for 
DMARC, then we might as well come up with a new DKIM Policy model and 
a new resource record lookup name.

Imo, you guys are really missing the boat here.  Extended tags is a 
major part of a DKIM POLICY model future simply because we have not 
yet imagine all the needs to make it work well and integrate with 
other concepts.  In DSAP, for example, we had tags such as:

+============================================================+
| Description            |  DSAP Record Tag                  |
|============================================================|
| Version tag            |  v=<dsap-version>/<dkim-version>  |
|------------------------------------------------------------|
| Original party signing |  op=<signing-policy>              |
| practice               |                                   |
|------------------------------------------------------------|
| 3rd party signing      |  3p=<signing-policy>              |
| practice               |                                   |
|------------------------------------------------------------|
| Authorized List of     |  dl=<dom-list>                    |
| 3rd party domains      |                                   |
|------------------------------------------------------------|
| Signature Hashing      |  a=<hash-algorithm>               |
| Method                 |                                   |
|------------------------------------------------------------|
| Reporting address      |  r=<abuse-address>                |
|------------------------------------------------------------|
| Note or comment        |  n=<note>                         |
|------------------------------------------------------------|
| Testing flag           |  t=<testing-flag>                 |
|------------------------------------------------------------|
| Unauthorized signature |  fa=<failure-handling>            |
| failure handling       |                                   |
|------------------------------------------------------------|
| Invalid Signature      |  fs=<failure-handling>            |
| failure handling       |                                   |
|------------------------------------------------------------|
| Signature Expiration   |  fx=<failure-handling>            |
| failure handling       |                                   |
+------------------------------------------------------------+

The optional note tag (n=) allows a domain to store a human readable 
note or comment regarding the DSAP DNS record.  Its purpose is 
considered to be diagnostic in nature.

The fa=, fs= and fx= tags were based on discussion to offer specific 
handling instructions based on specific possible errors:

4.8.  DSAP Tags: fa=<failure-handling>; fs=<failure-handling>;
       fx=<failure-handling>;

    The fa=, fs, and fx= tags define the domain preferred rejection
    action policy a verifier is recommended to perform when an
    unauthorized signature, failed signature or expired signature is
    detected, respectively.

    The fa= tag defines the handling for failed signature authorization.
    The fs= tag defines the handling for failed signature verfication,
    and the fx= tag defines the handling when a signature expired or key
    is revoked.

    Failed signature include failures related to the DKIM-Signature
    hashing, syntax and encryption verification process.

    <failure-handling> values:

    FAIL                The verifer MUST reject the transaction when
                        failure is detected.  (Default)

    SOFTFAIL            The verifer SHOULD reject the transaction when
                        failure is detected.

    IGNORE              The verifer SHOULD NOT reject the transaction
                        when failure is detected.  This value may be
                        defined by the domain to signify the domain is
                        testing DKIM and failure may occur unexpectedly.
                        Verifiers SHOULD consider tracking this handler
                        value for abuse.

    The fa= and fs= tags are optional with default values of SOFTFAIL.

    Examples:

    fa=fail;fs=fail; fx=fail;  Domain has a MUST reject immediate policy
                        for unauthorized, failed or expired signatures.

    fa=fail;            Domain has a MUST reject immediate policy for
                        unauthorized signatures and a SHOULD reject
                        immediate policy for failed and expired
                        signatures.

    undefined values;   DOMAIN has a SHOULD reject immediate policy for
                        all failures.

    fs=fail;  fx=fail;  Domain has a SHOULD reject immediate policy for
                        unauthorized signatures and a MUST reject
                        immediate policy for failed and expired
                        signatures.


My point is simple, extended tags MUST be part of the protocol's 
extendability. If there is evidence with 100% sureness there going to 
be a significant compatibility problem with legacy software that can 
not be corrected, then the only option is a new DMARC version 2 
resource record.

I don't think we (I know I can't) can continue with DMARCbis without 
Extended Tag support and be hesitant to invent them because there is a 
compatibility problem.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos