Re: [Ietf-dkim] DKIM-FBL

[Jesse Thompson]

On Wed, Sep 27, 2023, at 9:06 AM, Alessandro Vesely wrote:
> On 9/27/23 13:36, Brotman, Alex wrote:
> > I've attached a draft that uses attributes of a passing DKIM 
> > signature to create a DNS label that can be used to discover an FBL 
> > address.  This feedback address can be used by message receivers to 
> > provide a copy of FN (and potentially FP) (Spam/Not-Spam) reports to 
> > the DKIM signers.  This allows for entities to perhaps sign with more 
> > than one signature, and provide feedback to each signer if desired 
> > (or each can list multiple rcpts if desired).  With traditional FBLs, 
> > the lookup is likely based off the final sender IP address, which 
> > could be the original sender, or an intermediary.  This DKIM-based 
> > method could aid both MBPs and ESPs in fighting outbound abuse from 
> > their platforms.  There are also methods in the document to attempt 
> > to do more to make reports smaller, aiding storage and PII concerns. 
> > Thanks for your time and feedback.
> 
> I'm not clear why would DKIM selectors (s=) be involved in the DNS name 
> generation.  There are people who change selector for each message.  In 
> general, selectors play no role in identification and are solely used 
> for key rotation.  

I'm with Ale's thought process on using d= instead of s=.

Briefly, I thought that putting the DNS label under the selector would be great 
for situations when the selector is delegated via CNAMEs (and hence any 
subdomains would also be delegated), but I was conflating CNAME delegation with 
NS. The domain owner would have to publish the label in DNS in addition to the 
CNAME, and we know how difficult it is for most domain owners to modify their 
DNS.

As discussed in the other thread, it is common for messages to carry signatures 
for multiple domains (not all are rfc5322.From aligned), indicating a shared 
responsibility. The responsible party(ies) capable of receiving FBLs would 
publish the DKIM-FBL label in DNS under their signatory domain and not depend 
on a different domain owner (bad senders would not want feedback to go to the 
ESP/intermediary)

> I guess your spec derives from seeing per-campaign 
> selectors, but I doubt it is a common habit.  I'd suggest using 
> subdomains for such purpose.

I think adding a third signature in a subdomain, with a name that has some 
meaning (campaign, category, etc) would be an alternative to how the 
non-standard Feedback-Id header is in use today.

> For discussion, it'd be interesting to analyze similarity and 
> differences with List-Unsubscribe:, for FNs. 

It seems logical that List-Unsubscribe could have supplanted FBLs in some ways. 
Is there hope for that? I don't think it's common for MBPs to post an 
unsubscribe when users report spam. So, I think the only way this discussion 
idea has merit is if everyone starts treating spam complaints and 
unsubscriptions the same way.

If the sender doesn't add a List-Unsubscribe header, does that mean the 
ESP/intermediary should add one in order to get this "FBL equivalent" event 
stream for the messages it is partially responsible? 

Can there be two of these headers for situations when the unsubscribe, spam 
complaint, bounce suppression, compromised credential detection, DKIM replay 
detection, etc, processes are a shared responsibility between the sender and 
the ESP/intermediary? 

I assume that would introduce risk of DKIM signature breakage. This is one of 
the reasons why I like this DKIM-FBL approach of using DNS for discovery rather 
than the other idea to use headers to specify the complaint address. I think 
any situation involving intermediaries or delegated sending of existing headers 
should not depend on adding headers that may or may not already exist.

> How would a MBP decide 
> whether to make use of one, the other, or both methods to signal its 
> user's reaction?

I think the logic/situation would be:

1. The user doesn't like this message

2. The message may or may not have a List-Unsubscribe header - which may or may 
not have a functioning unsubscribe process. The MBP may or may not treat spam 
complaints as equivalent to unsubscribe requests, and vice versa. 

3. The message is DKIM signed by two different domains, which indicates there 
are multiple authenticated parties responsible for the message being sent. The 
delineation line for the responsibilities and capabilities of each party will 
be highly inconsistent and unknown to the MBP.

4. If one or both of these parties publish the label in DNS under their 
respective d= domains, this indicates that they are capable of receiving the 
feedback, and the MBP can/should send feedback to each responsible party to 
indicate that the user didn't like the message

5. Each report receiver incorporates the feedback into appropriate action 
pertaining to their area of responsibility.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org

[Ietf-dkim] Usage of RFC 6651 for replay-mitigation interoperability reporting (was Re: What makes this posting different from the original posting?)

[Jesse Thompson]

On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote:
> On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson  wrote:__
>>>> Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in 
>>>> control of the signer, as opposed to the attacker.
>>> 
>>> Has anyone (else) implemented it?
>> 
>> That's what I want to understand. Or, more specifically, if no one 
>> implemented it, why? And have those blockers changed due to the changed 
>> landscape with dkim replay, etc.
> 
> When DKIM was young, a mechanism like the one defined in RFC 6651 was 
> enormously valuable to me when two implementations were trying to debug 
> interoperability problems.  It allowed us to see why signatures were failing. 
> Once all the bugs were worked out and things like canonicalization and common 
> MTA mutations were well understood, the need for this sort of thing faded 
> away.

DKIM Replay is leading to interoperability problems as result of local policies 
being rolled out to mitigate the abuse, and senders (and their customers) need 
to make changes to their configuration to not get caught up in the emerging 
algorithms. Examples may include duplicate message throttling, blind recipient 
limitations, tighter expiration enforcement, etc. 

I think usage of the 'p' and 'x' reports and the 'rs' tag would be valuable 
(perhaps enormously, as you experienced first hand)

   pReports are requested for signatures that are rejected for local
policy reasons at the Verifier that are related to DKIM
signature evaluation.

   xReports are requested for signatures rejected by the Verifier
because the expiration time has passed.

  rs=  Requested SMTP Error String (plain-text; OPTIONAL; no default).
The value is a string the signing domain requests be included in
[SMTP <https://www.rfc-editor.org/rfc/rfc6651.html#ref-SMTP>] error 
strings when messages are rejected during a single
SMTP session.

The usage of "rejected" here is interesting because I'm seeing permanent 4xx 
throttling being employed for the duplicate message local policy limits, not 
rejects. I assume it's common for throttling to be employed before outright 
rejection, perhaps under the assumption that the message could be retried in a 
different fashion in order to be accepted. But without additional details about 
how the message could be retried, it is effectively equivalent to rejecting.

> Thus, I never heard of any implementations besides the first one.

Looking at passive DNS data... Only 16 domains had the _report._domainkey. 
record historically (as observed by queries through the collectors on the 
participating recursive resolvers). 3 have/had spf record values. Low query 
counts on all, suggesting that they don't add r= to their dkim-signatures, or 
there aren't many significant report generators issuing queries for the record 
through the participating resolvers.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Jesse Thompson]

On Thu, Sep 7, 2023, at 11:42 PM, Murray S. Kucherawy wrote:
> On Thu, Sep 7, 2023 at 9:38 PM Jesse Thompson  wrote:
>> __
>> Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in 
>> control of the signer, as opposed to the attacker.
> 
> Has anyone (else) implemented it?

That's what I want to understand. Or, more specifically, if no one implemented 
it, why? And have those blockers changed due to the changed landscape with dkim 
replay, etc.

Jesse

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Jesse Thompson]

On Thu, Sep 7, 2023, at 12:02 PM, Dave Crocker wrote:
> On 9/2/2023 7:29 AM, Jesse Thompson wrote:
>> On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
>>> DKIM, SPF, et al, are all 'collaborative' mechanisms.  Originators and 
>>> receivers opt in to use them.  Both sides are necessary.  So I'm wondering 
>>> about looking for something the furthers the collaboration.
>> 
>> The lack of reporting to the originating DKIM signers about Replay and other 
>> kinds of DKIM failure modes is an example of "limitations at the sending 
>> side [...] trying to detect". Alex and I are starting to draft a proposal 
>> for receivers to report to signers using rfc5965 and rfc7489 semantics.
> Since a Replay Attack has the act of replaying being done by an attacker, it 
> would not help to have a reporting mechanism for DKIM, because the attacker 
> would not use it.
> 
> If you are thinking of reporting by the later receiving platform, how would 
> this get used?
> 

Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in 
control of the signer, as opposed to the attacker.

Jesse ___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Jesse Thompson]

On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
> DKIM, SPF, et al, are all 'collaborative' mechanisms.  Originators and 
> receivers opt in to use them.  Both sides are necessary.  So I'm wondering 
> about looking for something the furthers the collaboration.

The lack of reporting to the originating DKIM signers about Replay and other 
kinds of DKIM failure modes is an example of "limitations at the sending side 
[...] trying to detect". Alex and I are starting to draft a proposal for 
receivers to report to signers using rfc5965 and rfc7489 semantics. 

Even with the best FBLs, it is too reactionary to prevent the "single message" 
from slipping through, not to mention all of the other scenarios discussed in 
this conversation. The originator has to make a boolean decision, based on 
limited and untimely information, about whether to send the message. So, we 
need a mechanism for receivers/evaluators to look up additional information 
about the context in which the message was originally signed (i.e. Ale's "Use 
segmented signature domains")

Does it make sense to address the evaluator-->signer and signer-->evaluator 
feedback problem in a unified document, or keep them separate?

I have thoughts that an out of band lookup mechanism (i.e. via signer-hosted 
DNS policy/intent records and signer-hosted DNSxL hash tables keyed on d= 
domains) is needed for evaluators to understand the meaning of the different d= 
subdomain signatures that a signer has applied to a message. 

> And the attacker can't bypass it, if the signature covers enough (or all) of 
> the message.
> 

The "new header field" (or similar) approach alone would not open any doors for 
revocation/invalidation of the fact that the signature was applied on that 
first single message. Relying solely on fast key rotation/invalidation would 
mean TTLs would need to be very low to have any effect. 

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Replay attack definition discussion

[Jesse Thompson]

On Sun, Aug 20, 2023, at 6:13 AM, Alessandro Vesely wrote:
> On Fri 18/Aug/2023 12:21:31 +0200 Emanuel Schorsch wrote:
> >>
> >>> For example, we have seen very large DKIM Replay attacks of youtube.com 
> >>> Terms of Service emails. There is no malicious content in these emails, 
> >>> but spammers still send very large volumes (perhaps using them to 
> >>> generate affinity with victims or warm up their sending 
> >>> infrastructure). >>
> >> That points to a bug in the I-D.  Section 3.1 says:
> >>
> >>  A spammer will find a mailbox provider with a high reputation and that
> >>  signs their message with DKIM. The spammer sends a message with spam
> >>  content from there to a mailbox the spammer controls.
> >>
> >> Youtube.com Terms of Service emails don't seem to have been sent by the 
> >> spammer.
> >
> > I agree, for completeness we should update that section to include both 
> > types of DKIM replay. I can work on sending a tweak to that section.
> 
> 
> Please do!  Without it, Section 5.3, "Strip DKIM signatures on mailbox 
> delivery" makes little sense.
> 
> 
> > But, to be clear this type of replay is definitely much less common than 
> > the spammer generated content. I just wanted to provide that it does also  
> > happen.
> 
> If there is a large difference, then the idea of segmenting authentication 
> domains might actually belong to countering replay attacks, for spammers 
> looking for high reputation signatures.  Some time ago I proposed 
> d=bullshit.example.com, but after thinking a bit more, the I-D could set up a 
> register for that.
> 
> For a strawman:
> 
>5.6. Use segmented signature domains
> 
>   Domains that host mailboxes for widely different categories of users,
>   typically free-mail domains, can differentiate the signature they affix
>   on messages by using subdomains.  IANA maintains a register of 
> subdomains
>   used for this purpose (See Section 7.)
> 
>   *  Messages written by spammers who get categorized as such will be
>  signed by subdomains with low reputation, which lowers the incentive
>  to obtain the very signature.
> 
>   *  Careful users, who don't spam and don't have their accounts often
>  compromised, can use domains whose reputation won't be ruined by
>  replay attacks.
> 
> And
> 
>7. IANA Consideration
> 
>   This document proposes the use of subdomain to categorize email message
>   categories for which IANA is to create and maintain a new registry
>   entitled "DKIM Semantic Subdomain Names".
> 
>   New registrations are published in accordance with the "First Come First
>   Served" guidelines as described in [RFC8126].  They are to contain the
>   following information:
> 
>   1.  Subdomain name to be used in the category.  The name MUST exist as a
>   direct subdomain for the domain referred by the proponent, and MUST
>   contain a non-empty _domainkey subdomain at the time or 
> registration.
> 
>   2.  Short description of the category, and criteria for assigning 
> messages
>   to this category, possibly containing a link to extended 
> description.
> 
>   3.  Trust that recipients are invited to assign to messages signed by 
> such
>   subdomain.  This MUST be one of the key words "none", "low", 
> "medium"
>   and "high".
> 
>   4.  Date of the registration.
> 
>   Note: Domains are invited to re-use existing names rather than 
> registering
>   new ones, if the intent matches the description.  These names are not
>   visible by users, so there is no reason to use IDNs.  Names and
>   descriptions MUST be in English.

I just want to say +1 to all of this. I believe that adding more d= signatures 
to convey context is the solution to allow ESPs/intermediaries to express 
enough information to allow receivers to make a mail handling decision in a way 
that minimizes collateral damage.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Replay attack definition discussion

[Jesse Thompson]

On Thu, Aug 17, 2023, at 5:30 AM, Alessandro Vesely wrote:
> When domain authentication arrived, they considered that /all/ messages from 
> their domain must be authenticated. 

Some receivers only send FBLs if the messages are DKIM=pass. So, the 
responsible thing to do is for a MBP/ESP to sign everything to maximize 
visibility on abuse.

> DMARC reporting is specifically aimed at such goal.

MBP/ESPs which allow customers to bring their own domain do not have visibility 
into DMARC reports; especially from bad actors who don't want their provider to 
see what they are doing.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] replay is a bogus concept

[Jesse Thompson]

On Thu, Aug 17, 2023, at 12:02 PM, Steffen Nurpmeso wrote:
> More, usually (it happened in the past) they then point to their
> web site, where you then *do*, and isn't the certificate of that
> website, which itself is likely verified by some CA in some CA
> pool that you do not have control over, or do not exert control
> over, also because the interface is user unfriendly, a much bigger
> problem, also security-wise, than the DKIM signature?  Especially
> with DNSSEC etc etc?

If I understand correctly, there are some "no auth, no entry" requirements 
being suggested by some ISPs, in which they might start requiring DKIM 
signatures aligned to any/all domains in headers and body. 

I guess it's not enough that the web site has a CA cert, since those are 
trivial to obtain. So, now the CA problem shifts to DKIM.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Replay attack definition discussion

[Jesse Thompson]

On Wed, Aug 16, 2023, at 8:26 AM, Laura Atkins wrote:
> 
> 
>> On 16 Aug 2023, at 12:59, Alessandro Vesely  wrote:
> 
>> BTW, how many replay attacks does an average ESP or MP notice in one month?
> 
> Maybe representatives of either group could offer numbers.

ESPs have limited visibility because feedback is mostly sent to the whois 
contact of the infrastructure emitting the replay (unless specific feedback 
mechanics are set up for DKIM signers)

https://www.rfc-editor.org/rfc/rfc6650#section-5.3

Where an abusive message is authenticated using a domain-level
authentication technology such as DKIM [RFC6376] or SPF [RFC4408],
the domain that has been verified by the authentication mechanism is
often a reasonable candidate for receiving feedback about the
message.  For DKIM, though, while the authenticated domain has some
responsibility for the mail sent, it can be a poor contact point for
abuse issues (for example, it could represent the message's author
but not its sender, it could identify the bad actor responsible for
the message, or it could refer to a domain that cannot receive mail
at all).

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Mon, Aug 14, 2023, at 11:08 AM, Dave Crocker wrote:
> MTAs that are doing MTA functions are not supposed to make changes to 
> the content and typically they don't.

I'm not designing a typical MTA. I want to design one that doesn't allow DKIM 
replay.

Jesse ___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Sat, Aug 12, 2023, at 9:00 PM, Murray S. Kucherawy wrote:
> Lastly, I suggest that we've wandered pretty far afield from talking about 
> the problem statement document.

Agreed. I realize my participation in exploring the feasibility of the solution 
space is a rabbit hole for purposes of agreement on the problem statement. 

I'm open to private feedback/coaching about my approach. Like I said, I plan to 
be in Brooklyn.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Fri, Aug 11, 2023, at 4:34 PM, Steffen Nurpmeso wrote:
> Jesse Thompson wrote
> The aspect of DKIM-subsignatures revealing Bcc: presence (of 1+
> recipients of a domain) if a Bcc: recipient replies to a message
> that Murray Kucherawy adduced i obviously have not fully addressed
> with my response.

If I reply to a message that contains no Bcc header I am revealing the fact 
that I received the message. I don't understand this issue. Are you conflating 
the issue with forwarding?


> DKIM is meant to be automated in between machines.
> Today it pledges one side, the sender one, but with this, if we
> throw in the american style we could call it "smart" or
> "reflective" DKIM, the pledge is extended to be in between sender
> and receiver.

This is an argument for removing DKIM signatures for any submitted messages, so 
the ESP can add their own signature which includes the RCPT TO or signed Bcc. 
The main blocker for ESPs doing that is their customers may require to apply 
their own signatures instead of delegating their domain's keys to the ESP. So, 
ESPs would need to only allow that for trusted customers and spammers will try 
to appear trusted and/or continue to exploit compromised credentials of trusted 
customers.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Wed, Aug 9, 2023, at 3:12 PM, Murray S. Kucherawy wrote:
> On Wed, Aug 9, 2023 at 9:07 AM Steffen Nurpmeso  wrote:
>> All these problems are long known to (and "solved" by) the OpenPGP
>> (and S/MIME) communities, no?
>> In OpenPGP you can either encrypt-to a single or many recipients.
>> (With at least GnuPG you can also "hide" those recipients:
>> 
>>‐‐hidden‐recipient name
>>‐R Encrypt  for  user  ID  name, but hide the key ID of this 
>> user’s
>>   key. This option helps to hide the receiver of the  message  
>> and
>>   is  a  limited  countermeasure against traffic analysis. If 
>> this
>>   option or ‐‐recipient is not specified, GnuPG asks for the  
>> user
>>   ID unless ‐‐default‐recipient is given.
>> 
>> ).  (Also GnuPG just recently introduced a "company-super-key" like
>> thing, as it seems many work groups etc. need to encrypt to each
>> member, and then the communication must be archived, with the
>> possibility to decrypt years later.  But, eh, only for
>> completeness.)
> 
> There aren't per-user DKIM keys.  I mean, there could be, but that's not how 
> it's designed or maintained.
> 
> So the best you could do is per-recipient-domain signatures, but I don't 
> think that solves much: If I launch a replay attack from gmail.com at 
> yahoo.com, or even simply back at gmail.com, I can still hit a large number 
> of recipients without needing an array of signatures or revealing that replay 
> is occurring.
> 
>> Isn't this discussion about Bcc: off-topic and solely RFC 5322?
>> I have never seen a MUA implementation which does anything else
>> but "throwing recipients into" To:/Cc:/Bcc:.  And then there is
>> "undisclosed-recipients", where anything is consciously not part
>> of IMF/5322, but only in SMTP/5321, but still per-recipient DKIM
>> should work out, then.
> 
> "Bcc" came up in the context of supporting DARA as a solution to the replay 
> problem, I believe.

I brought "Bcc" up IIRC because I was thinking about "5.1.  Include the SMTP 
RCPT-TO address in the DKIM signature" and this basically means that the Replay 
problem is because the recipient is blind. There's already a header for blind 
recipients: Bcc. Headers can be signed, hence it would be "in the signature". 
Individual messages can be sent to each recipient, each with their own 
signed-Bcc. Only the recipient sees their address in Bcc, so there's no privacy 
concern unless the receiving server/client doesn't strip it and the message is 
forwarded. I don't think DARA was on my mind, but maybe.

Any inclusion of RCPT-TO in the headers or signature is a privacy concern if 
the message is forwarded, but those tend to show up in Received headers anyway. 
Seems like a wash, regardless of where you put it.

I am thinking that a solution could be for an MSA to add any header (Bcc, 
Forwarded-to, etc) and sign it (optionally, since the existence of the RCPT-TO 
in the header is enough for receiving organizations to weed out Replays). But 
the mention of PGP and S/MIME makes me realize that practice may break 
legitimate submitted signed messages, including DKIM signed messages with those 
headers in its signature. 

If the header approach is chosen, MSAs must ensure it can't be a signed header 
during message submission. MSAs accepting the signed header becomes prohibited 
(if detectable) as much as "open relays" were shunned into non-existence (which 
seems like an effective and transparent motivator to adoption). "if detectable" 
is the main unknown in my mind. The MSA should add their own signature, which 
signs the header attesting that the MSA added it, and ensure that no other 
signature has that header signed. Something along those lines?

Or put the RCPT-TO address as a tag in the signature that the MSA adds. Seems 
cleaner than adding normal headers and less risk of breaking prior signatures. 
The downside is that the long tail of DKIM evaluators may ignore the MSA's 
signature and only look at the original signature, which might be a Replay. 
This is why I like Bcc. It may break things, but it breaks things not so badly, 
and those minor breakages become a motivator to change.


>> It seems to me that adding a per-recipient DKIM "sub-signature"
>> can be accomplished very cheaply, and "scales to
>> super-parallelism".
> 
> If by that you mean a distinct signing key per user, I don't think this 
> scales.  That's not because DKIM can't handle it, but because I don't think 
> large operators like Gmail or Yahoo want to maintain millions of public keys 
> in their DNS.

I don't like the idea of distinct *keys* per recipient for those reasons, but I 
do like the idea of distinct *signatures* per recipient (which is accomplished 
by including RCPT-TO in the signature).

Key distinction should be aiming for more granularity at the sender level. 
Domain > campaign/application > user/credential > message. Senders will be 
motivated to add key granularity 

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Tue, Aug 8, 2023, at 5:18 AM, Laura Atkins wrote:
>> On 6 Aug 2023, at 19:07, Jesse Thompson  wrote:
>> 
>> On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
>>>> On 5 Aug 2023, at 02:43, Jesse Thompson  wrote:
>>>> 
>>>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
>>>>> I agree with this and have been working to recruit folks to come here. 
>>>>> I’ll also be in Brooklyn and pitching the need for participation in the 
>>>>> IETF working group from folks in the email space who are seeing issues 
>>>>> with this. 
>>>> 
>>>> I'll be there and interesting in participating. As an ESP/infrastructure 
>>>> provider I can say that we are "having" the issue, but can't say that we 
>>>> "seeing" the issue since visibility is only available to anti-spammers, 
>>>> and domain owners (who receive DMARC reports). 
>>> 
>>> A big driver of the work is actually Google. As I understand it, they are 
>>> having issues because the replay attackers are successfully stealing 
>>> reputation of otherwise good senders in order to bypass some spam 
>>> filtering. The replay attackers aren’t sending what we commonly think of as 
>>> spam through the signers - as the message is sent to one recipient (not 
>>> bulk) and it is opt-in (that recipient wants and has asked for the mail). 
>> 
>> This is accurate from my observation. It takes only a single message which 
>> evades content filters, and the attacker is the first recipient, who will 
>> not report it as abuse. 
>> 
>> Which is why an earlier "just don't send spam" comment seemed to be 
>> borderline FUSSP rhetoric. If the message isn't detected by the receiver 
>> (who has the most visibility into the type of mail its users want to 
>> receive) then how can a sender be held to a higher standard of detection 
>> with less visibility?
> 
> I agree wholeheartedly. I just wanted to make it clear for the record that 
> this isn’t an issue of the signer knowingly signing spam and “deserving” any 
> reputation problems. 
> 
>> The reputation they are stealing is that of the DKIM domain(s) associated 
>> with the signatures on the message (whether they are aligned to the 
>> rfc5322.From or not). So, adding more signatures to convey more fidelity 
>> would seemingly help solve the problem because receivers could better 
>> fingerprint good patterns from bad patterns. But replayers could just remove 
>> the higher fidelity signatures. 
>> 
>> To solve that, I think we need Mandatory Tags for DKIM Signatures [1] 3.3. 
>> Forward signature (!fs) tag.
>> 
>> [1] https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04
>> 3.3. Forward signature (!fs) tag
>> The "!fs" mandatory tag means that the signature is only valid if an 
>> additional signature is present in the message. The value of the !fs tag is 
>> a domain name that is the value of the d= tag of the additional signature. 
>> The condition is satisfied if the message includes at least one valid DKIM 
>> signature header field with responsible domain (the d= tag) being one 
>> specified by the !fs tag. Chained !fs tags are valid and may be useful in 
>> scenarios with multiple levels of forwarders. DKIM verifiers SHOULD handle 
>> at least three levels of !fs chaining.
> 
> I’ll have to read that more fully, but a brief read through seems to indicate 
> this isn’t the solution to the replay problem. To whit:
> 
> "6. Security Considerations
> It opens up a variety of obvious replay attacks that may or may not be 
> important depending on both the selection of target domains for messages to 
> be forwarded, and the behavior of forwarders that receive messages with 
> conditional signatures.”

It doesn't stop replay. It allows for fine-grained identification of mail 
streams as well as an opportunity for invalidation of individual mail streams.


> Also, I’m not sure how it will work on mail that isn’t expected to be 
> forwarded. 

I wasn't intending to solve the forwarding problem. I'm a proponent of munging 
(not sure if you want to have that debate here instead of the other list). I am 
trying to keep an open mind on that. I am of increasingly of the opinion that 
the challenges for mailing lists are not very different than the challenges for 
ESPs, so the solutions might start to converge.


>>>> I recall various assertions that the reason why DMARC has been successful 
>>>> is primarily because of the Reporting benefits (and I certainly agree with 
>>>> this

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Tue, Aug 8, 2023, at 12:55 AM, Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 9:23 PM Jesse Thompson  wrote:
>> __On Mon, Aug 7, 2023, at 10:54 PM, Murray S. Kucherawy wrote:
>>> On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch 
>>>  wrote:
>>>> If there are not that many BCC recipients for a message then it is likely 
>>>> not necessary as the duplicate message counting is unlikely to have a 
>>>> negative impact. If there are a large number of BCC recipients for a given 
>>>> message then I think the solutions proposed in Wei's DARA draft are 
>>>> helpful: standardizing the way to indicate BCC/Forwarded-To and signing a 
>>>> separate copy of the message for each BCC recipient so that it can still 
>>>> be verified as direct mail.
>>> 
>>> Doesn't putting "invisible" recipients into an actual field like Bcc create 
>>> a privacy concern, i.e., they're no longer invisible?  You need to hope 
>>> that the agents in the handling chain that are supposed to delete that 
>>> field will actually do it, which presumes the entire deployed base will 
>>> adopt DARA in a reasonable period of time.
>> 
>> According to RFC 5322 it should be handled correctly by "but the recipients 
>> on the "Bcc:" line get a separate copy of the message containing a "Bcc:" 
>> line"
>> 
>> [...]
> 
> As you cited, RFC 5322 describes three ways that the "Bcc" field is typically 
> used.  You're talking about just one of those, and I'm not sure it's the most 
> common one.  In any case, I suggest that "should" is a bit of a leap, 
> especially given that the choice of which of the three to use is described as 
> "implementation dependent".
> 
> The second part of your citation confirms the risk to which I was referring.

I don't understand why it's a privacy issue that an individual recipient sees 
their own address in the Bcc header.

Jesse
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Tue, Aug 8, 2023, at 6:37 AM, Scott Kitterman wrote:
> On August 8, 2023 10:18:58 AM UTC, Laura Atkins  
> wrote:
> >> On 6 Aug 2023, at 19:07, Jesse Thompson  wrote:
> >> 
> >> On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
> >>>> On 5 Aug 2023, at 02:43, Jesse Thompson  >>>> <mailto:z...@fastmail.com>> wrote:
> >>>> 
> >>>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
> ...
> >>> 
> >>> A big driver of the work is actually Google. As I understand it, they are 
> >>> having issues because the replay attackers are successfully stealing 
> >>> reputation of otherwise good senders in order to bypass some spam 
> >>> filtering. The replay attackers aren’t sending what we commonly think of 
> >>> as spam through the signers - as the message is sent to one recipient 
> >>> (not bulk) and it is opt-in (that recipient wants and has asked for the 
> >>> mail). 
> >> 
> >> This is accurate from my observation. It takes only a single message which 
> >> evades content filters, and the attacker is the first recipient, who will 
> >> not report it as abuse. 
> >> 
> >> Which is why an earlier "just don't send spam" comment seemed to be 
> >> borderline FUSSP rhetoric. If the message isn't detected by the receiver 
> >> (who has the most visibility into the type of mail its users want to 
> >> receive) then how can a sender be held to a higher standard of detection 
> >> with less visibility?
> >
> >I agree wholeheartedly. I just wanted to make it clear for the record that 
> >this isn’t an issue of the signer knowingly signing spam and “deserving” any 
> >reputation problems. 
> ...
> 
> Intent has nothing to do with it.  Reputation is what you do, not what you 
> intend.

I think we can agree that spammers will always exist because they are a 
societal problem. Societal problems can't be completely solved with technology. 
Spammers will find ways to leverage the technologies we build to leverage in 
their ill will. DKIM didn't intend to give a haven for spammers to hide behind 
DKIM signers, but that's what it does. DKIM replay is a problem that is going 
to persist as long as society has spammers. Yet, DKIM isn't designed to solve 
spam problems. It conveys identifiable and verifiable information. DKIM signers 
will not be able to identify 100% of what a receiver will consider spam, but 
they can provide additional verifiable information for receivers to interpret 
into their disposition.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Mon, Aug 7, 2023, at 10:54 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch 
>  wrote:
>> If there are not that many BCC recipients for a message then it is likely 
>> not necessary as the duplicate message counting is unlikely to have a 
>> negative impact. If there are a large number of BCC recipients for a given 
>> message then I think the solutions proposed in Wei's DARA draft are helpful: 
>> standardizing the way to indicate BCC/Forwarded-To and signing a separate 
>> copy of the message for each BCC recipient so that it can still be verified 
>> as direct mail.
> 
> Doesn't putting "invisible" recipients into an actual field like Bcc create a 
> privacy concern, i.e., they're no longer invisible?  You need to hope that 
> the agents in the handling chain that are supposed to delete that field will 
> actually do it, which presumes the entire deployed base will adopt DARA in a 
> reasonable period of time.

According to RFC 5322 it should be handled correctly by "but the recipients on 
the "Bcc:" line get a separate copy of the message containing a "Bcc:" line"

   The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
   addresses of recipients of the message whose addresses are not to be
   revealed to other recipients of the message.  There are three ways in
   which the "Bcc:" field is used.  In the first case, when a message
   containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
   removed even though all of the recipients (including those specified
   in the "Bcc:" field) are sent a copy of the message.  In the second
   case, recipients specified in the "To:" and "Cc:" lines each are sent
   a copy of the message with the "Bcc:" line removed as above, *but the
   recipients on the "Bcc:" line get a separate copy of the message
   containing a "Bcc:" line.*  (When there are multiple recipient
   addresses in the "Bcc:" field, some implementations actually send a
   separate copy of the message to each recipient with a "Bcc:"
   containing only the address of that particular recipient.)  Finally,
   since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
   sent without any addresses indicating to the recipients that blind
   copies were sent to someone.  Which method to use with "Bcc:" fields
   is implementation dependent, but refer to the "Security
   Considerations" section of this document for a discussion of each.

...

   Many implementations use the "Bcc:" (blind carbon copy) field,
   described in section 3.6.3 
, to facilitate 
sending messages to
   recipients without revealing the addresses of one or more of the
   addressees to the other recipients.  Mishandling this use of "Bcc:"
   may disclose confidential information that could eventually lead to
   security problems through knowledge of even the existence of a
   particular mail address.  For example, if using the first method
   described in section 3.6.3 
, where the "Bcc:" 
line is removed from the
   message, blind recipients have no explicit indication that they have
   been sent a blind copy, except insofar as their address does not
   appear in the header section of a message.  Because of this, one of
   the blind addressees could potentially send a reply to all of the
   shown recipients and accidentally reveal that the message went to the
   blind recipient.  When the second method from section 3.6.3 
 is used,
   the blind recipient's address appears in the "Bcc:" field of a
   separate copy of the message.  If the "Bcc:" field sent contains all
   of the blind addressees, all of the "Bcc:" recipients will be seen by
   each "Bcc:" recipient.  Even if a separate message is sent to each
   "Bcc:" recipient with only the individual's address, implementations
   still need to be careful to process replies to the message as per
   section 3.6.3  
so as not to accidentally reveal the blind recipient to
   other recipients.

Or maybe Resent-Bcc is more appropriate for situations in which an 
intermediary/ESP needs to insert a header

   Resent fields SHOULD be added to any message that is reintroduced by
   a user into the transport system.  A separate set of resent fields
   SHOULD be added each time this is done.  All of the resent fields
   corresponding to a particular resending of the message SHOULD be
   grouped together.  Each new set of resent fields is prepended to the
   message; that is, the most recent set of resent fields appears
   earlier in the message.  No other fields in the message are changed
   when resent fields are added.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Mon, Aug 7, 2023, at 10:24 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 7:43 PM Jesse Thompson  wrote:
>> __
>> Similar to what Emmanuel is saying about detecting SPF/DKIM zone 
>> misalignment, the solution to DKIM replay is for receivers to maintain some 
>> state and feed it into bespoke replay detection algorithms. If all receivers 
>> can maintain this kind of state, then there's nothing senders need to do, I 
>> suppose? Given that *normally* all of the messages we emit have unique 
>> message-ids, receivers can just limit the amount of duplicative message-ids 
>> they accept from us. Assuming they know the situations in which message-ids 
>> would not be unique. That's another thing that maybe needs to be 
>> communicated somehow as "this is normal in this situation".
> 
> Isn't this a derivative of the "Count DKIM signatures" approach identified in 
> the current problem statement document?  If so, do you have any comments on 
> the points against such an approach?

Yes, it is derivative. But I don't see why the solution needs to describe 
exactly how a receiver must fingerprint a mail stream. Presumably they 
can/will/do use all of the available information to get the most fidelity. 

The larger issue is how senders communicate to receivers how to correctly 
interpret the different signals. Receivers can choose whether to trust what the 
sender is communicating, and incorporate into their disposition.

Chained DKIM would use a domain as the key for receivers to index and look up 
this information, without having to invent a new header to be signed (which 
would then involve another internal policy lookup to see if they trust the 
signing domain, so why not just use the signing domain as the key).

DNSxL is a proven workable lookup mechanism, is it not?


> Since you specifically mention Message-IDs, does anyone have data on how 
> often that header field is included in signatures?  If it's not, then 
> rotating Message-IDs at random defeats such an approach and drives up the 
> receiver's operational cost to boot.

Can't speak for everyone. All I can say is that we sign message-ids and we use 
message-ids as the username part of the return path to ensure message-level 
attribution of such events. Our interest is to maximize visibility on bounces 
and other kinds of feedback to ensure customers adhere to deliverability best 
practices.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Mon, Aug 7, 2023, at 3:42 AM, Alessandro Vesely wrote:
> On Sun 06/Aug/2023 18:07:15 +0000 Jesse Thompson wrote:
> > On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
> >>> [...]
> >>>
> >> The replay attackers aren’t sending what we commonly think of as spam 
> >> through the signers - as the message is sent to one recipient (not 
> >> bulk) and it is opt-in (that recipient wants and has asked for the 
> >> mail). >
> > This is accurate from my observation. It takes only a single message which 
> > evades content filters, and the attacker is the first recipient, who will 
> > not report it as abuse.
> >
> > Which is why an earlier "just don't send spam" comment seemed to be 
> > borderline FUSSP rhetoric. If the message isn't detected by the receiver 
> > (who has the most visibility into the type of mail its users want to 
> > receive) then how can a sender be held to a higher standard of detection 
> > with less visibility?
> 
> 
> Good question!  They could implement RFC 7073 to exchange information based 
> on, say, the RFC5322.From field of the messages.
> 
> Let me contrast that idea with a small mailbox provider's POV.  Stock IMAP 
> server packages provide no tools to reckon users' liking of messages. 
> Reporting messages as spam also needs non-standard extensions.  (There is a 
> proposal to signal basic reaction to a message, RFC 9078, but it's not 
> implemented).

I'll need to read up on these.


> > The reputation they are stealing is that of the DKIM domain(s) associated 
> > with the signatures on the message (whether they are aligned to the 
> > rfc5322.From or not). So, adding more signatures to convey more fidelity 
> > would seemingly help solve the problem because receivers could better 
> > fingerprint good patterns from bad patterns. But replayers could just 
> > remove the higher fidelity signatures.
> >
> > To solve that, I think we need Mandatory Tags for DKIM Signatures [1] 3.3. 
> > Forward signature (!fs) tag.
> 
> 
> That would imply you know in advance that a message is going to be 
> replayed.  Having that knowledge, like when you send to a mailing list, you 
> can require that the replayer's signature be also present.  It wouldn't 
> suit the problem at hand.

Isn't the issue that any message signed by an intermediary or ESP can 
potentially be replayed?

Similar to what Emmanuel is saying about detecting SPF/DKIM zone misalignment, 
the solution to DKIM replay is for receivers to maintain some state and feed it 
into bespoke replay detection algorithms. If all receivers can maintain this 
kind of state, then there's nothing senders need to do, I suppose? Given that 
*normally* all of the messages we emit have unique message-ids, receivers can 
just limit the amount of duplicative message-ids they accept from us. Assuming 
they know the situations in which message-ids would not be unique. That's 
another thing that maybe needs to be communicated somehow as "this is normal in 
this situation". 

I am suggesting that chained DKIM keys would be a way for receivers to 
fingerprint different message streams to build models of what is normal vs 
abnormal.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Sun, Aug 6, 2023, at 2:00 PM, Emanuel Schorsch wrote:
> 
> 
> On Sun, Aug 6, 2023 at 11:52 AM Wei Chuang 
>  wrote:
>> 
>> 
>> On Sat, Aug 5, 2023 at 4:51 AM Laura Atkins  wrote:
>>> 
>>> 
>>>> On 5 Aug 2023, at 02:43, Jesse Thompson  wrote:
>>>> 
>>>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
>>>>> I agree with this and have been working to recruit folks to come here. 
>>>>> I’ll also be in Brooklyn and pitching the need for participation in the 
>>>>> IETF working group from folks in the email space who are seeing issues 
>>>>> with this. 
>>>> 
>>>> I'll be there and interesting in participating. As an ESP/infrastructure 
>>>> provider I can say that we are "having" the issue, but can't say that we 
>>>> "seeing" the issue since visibility is only available to anti-spammers, 
>>>> and domain owners (who receive DMARC reports). 
>> We don't have visibility either as DKIM replay from an authentication 
>> perspective looks like legitimate traffic.  Of course the content looks 
>> spammy which has a negative impact, and it's hard to differentiate DKIM 
>> replay from day to day variations.  
>>  
>>> A big driver of the work is actually Google. As I understand it, they are 
>>> having issues because the replay attackers are successfully stealing 
>>> reputation of otherwise good senders in order to bypass some spam 
>>> filtering. The replay attackers aren’t sending what we commonly think of as 
>>> spam through the signers - as the message is sent to one recipient (not 
>>> bulk) and it is opt-in (that recipient wants and has asked for the mail). 
>> 
>> Agreed.  For a while DKIM replay was our number one source on increased 
>> escalations, and that was heading towards an unsustainable place.  
>> Fortunately DKIM replay and escalations calmed down quite a bit, perhaps due 
>> to the ecosystem implementing various mitigation techniques.  For example 
>> we've had good success with the duplicate message counting idea reported at 
>> M3AAWG (and mentioned in the problem statement document), as well as many 
>> implementing other techniques.   My worry is that these techniques don't 
>> tackle the issue at the protocol level and several have thresholds that 
>> spammers can exploit.  I suspect they will be back once their current 
>> large-scale campaign with SPF runs its course.
>  
> To add to what Wei said, enforcing RFC5322 (duplicate Headers), and quota 
> limits on duplicate messages has been effective so far, and we will likely 
> continue to tighten those quota limits over time. The downside is that benign 
> non-DKIM replayed traffic might be affected by the message counting approach. 
> 
> There are certain criteria which indicate the message is NOT dkim replay. The 
> two simplest are: 1) The SPF zone and DKIM zone are aligned.
> 

What can ESPs do to make these zone boundaries easier for receivers to 
determine alignment in their disposition algorithms? Or rather, predictable 
non-alignment patterns? I know that you probably already have a clear picture 
by analyzing historical patterns, but many receivers won't take as much of an 
algorithmic/learning approach.


> 
> 2) The actual recipient is included in the DKIM signed message (non-BCC).
> 

For messages which are originally submitted as BCC and, depending on the 
circumstances, it's necessary for us to identify the recipient in the headers, 
what is/should be the standard header to use for this purpose? BCC? 
Forwarded-to?

Jesse 


> 
> Any message that meets either of these criteria can be excluded from 
> duplicate message quota limits. If there are cases where there would be large 
> volumes of duplicate messages that don't meet these criteria then that is a 
> case where we might need new standards to allow those indirect flows to 
> proceed unimpacted. Otherwise, if everyone is happy that their cases are 
> covered it might be that RFC5322 and DuplicateMessageCounting is enough to 
> mitigate the problem.
> 
> Note the goal here is not to prevent EVERY dkim replay message. The goal is 
> to make the possible amplification factor small enough that dkim replay is 
> not an attractive technique to spammers.
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
> ___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
>> On 5 Aug 2023, at 02:43, Jesse Thompson  wrote:
>> 
>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
>>> I agree with this and have been working to recruit folks to come here. I’ll 
>>> also be in Brooklyn and pitching the need for participation in the IETF 
>>> working group from folks in the email space who are seeing issues with 
>>> this. 
>> 
>> I'll be there and interesting in participating. As an ESP/infrastructure 
>> provider I can say that we are "having" the issue, but can't say that we 
>> "seeing" the issue since visibility is only available to anti-spammers, and 
>> domain owners (who receive DMARC reports). 
> 
> A big driver of the work is actually Google. As I understand it, they are 
> having issues because the replay attackers are successfully stealing 
> reputation of otherwise good senders in order to bypass some spam filtering. 
> The replay attackers aren’t sending what we commonly think of as spam through 
> the signers - as the message is sent to one recipient (not bulk) and it is 
> opt-in (that recipient wants and has asked for the mail). 

This is accurate from my observation. It takes only a single message which 
evades content filters, and the attacker is the first recipient, who will not 
report it as abuse. 

Which is why an earlier "just don't send spam" comment seemed to be borderline 
FUSSP rhetoric. If the message isn't detected by the receiver (who has the most 
visibility into the type of mail its users want to receive) then how can a 
sender be held to a higher standard of detection with less visibility?

The reputation they are stealing is that of the DKIM domain(s) associated with 
the signatures on the message (whether they are aligned to the rfc5322.From or 
not). So, adding more signatures to convey more fidelity would seemingly help 
solve the problem because receivers could better fingerprint good patterns from 
bad patterns. But replayers could just remove the higher fidelity signatures. 

To solve that, I think we need Mandatory Tags for DKIM Signatures [1] 3.3. 
Forward signature (!fs) tag.

[1] https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04
3.3. Forward signature (!fs) tag
The "!fs" mandatory tag means that the signature is only valid if an additional 
signature is present in the message. The value of the !fs tag is a domain name 
that is the value of the d= tag of the additional signature. The condition is 
satisfied if the message includes at least one valid DKIM signature header 
field with responsible domain (the d= tag) being one specified by the !fs tag. 
Chained !fs tags are valid and may be useful in scenarios with multiple levels 
of forwarders. DKIM verifiers SHOULD handle at least three levels of !fs 
chaining.


> 
>> I recall various assertions that the reason why DMARC has been successful is 
>> primarily because of the Reporting benefits (and I certainly agree with this 
>> assertion from my background as an enterprise domain owner), while the 
>> Conformance benefits seem to be more elusive (as evidenced by the 
>> inconsistent adoption by receivers and the debates around interoperability 
>> issues with indirect mail streams). Of course, the Authentication benefits 
>> are provided by DKIM/SPF, and yet DKIM signers have no standard mechanism to 
>> receive reports of how their signatures are being misused. 
>> 
>> If people think that Reporting is the reason why DMARC has been successful, 
>> then could we conclude that the lack of Reporting to DKIM signers is a 
>> problem worth addressing?
> 
> That’s an interesting thought. I’m thinking the next step down - will it help 
> minimize the problem for senders? ie, would reporting be fast enough that 
> they could revoke a key? 

The reason why key revocation doesn't work today (other than DNS TTL) is 
because the replayed keys are in domains that too broadly cover desirable mail. 
The key which should be revoked should be the one that most narrowly stops only 
the replayed mail and not stop otherwise good mail. In the high-fidelity 
multi-key model with forward signature tags, revocation of a single key to 
break the chain seems possible. How quickly it can be done is lower bound to 
how quickly a receiver's reputation algorithms can identify fingerprint any 
message down to the highest fidelity key, but the risk of DOS implies there 
needs to be some kind of moderation. 

I think the DNSxL approach is more flexible and timely than revoking the key 
from DNS. So, while anti-spammers are in a better position to create and 
maintain DNSxLs for thwarting replay attacks, I was thinking about a model 
where ESPs index customers with DKIM signatures in domains that are unique per

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
> I agree with this and have been working to recruit folks to come here. I’ll 
> also be in Brooklyn and pitching the need for participation in the IETF 
> working group from folks in the email space who are seeing issues with this. 

I'll be there and interesting in participating. As an ESP/infrastructure 
provider I can say that we are "having" the issue, but can't say that we 
"seeing" the issue since visibility is only available to anti-spammers, and 
domain owners (who receive DMARC reports). 

I recall various assertions that the reason why DMARC has been successful is 
primarily because of the Reporting benefits (and I certainly agree with this 
assertion from my background as an enterprise domain owner), while the 
Conformance benefits seem to be more elusive (as evidenced by the inconsistent 
adoption by receivers and the debates around interoperability issues with 
indirect mail streams). Of course, the Authentication benefits are provided by 
DKIM/SPF, and yet DKIM signers have no standard mechanism to receive reports of 
how their signatures are being misused. 

If people think that Reporting is the reason why DMARC has been successful, 
then could we conclude that the lack of Reporting to DKIM signers is a problem 
worth addressing?

The company I work for indexes very highly on measurability. If an initiative 
can't be measured, there is no way to measure its success, so it is very hard 
to prioritize.

Jesse___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim