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