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

2023-09-22 Thread Alessandro Vesely 

On Thu 21/Sep/2023 22:27:30 +0200 Brotman, Alex wrote:


Including that data in a DMARC report may not be very useful if it's going 
to the domain holder instead of the DKIM signer.  For example, SES signs all 
of their messages, but unless that 5322 owner shares the data, they wouldn't 
see any information relating to those signatures.



Yeah, they put two signatures, the first one having d=amazonses.com.  Their 
second signature is aligned with the From: domain, though.  DMARC reports 
include results of third party signatures, and SES may ask its account holders 
to share those reports.


A similar problem is going to occur when DMARC reports will include an ARC 
extension.  ARC sealers will most probably _not_ be related with the sender —if 
anything, they'd rather communicate with final receivers.


At any rate, it may be easier to tweak the behavior of an alive kid rather than 
trying to revive a dead one.



Best
Ale
--




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

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

2023-09-21 Thread Brotman, Alex 
Ale,

Including that data in a DMARC report may not be very useful if it's going to 
the domain holder instead of the DKIM signer.  For example, SES signs all of 
their messages, but unless that 5322 owner shares the data, they wouldn't see 
any information relating to those signatures.

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

> -Original Message-
> From: Ietf-dkim  On Behalf Of Alessandro Vesely
> Sent: Friday, September 15, 2023 5:29 AM
> To: ietf-dkim@ietf.org
> Subject: Re: [Ietf-dkim] Usage of RFC 6651 for replay-mitigation 
> interoperability
> reporting (was Re: What makes this posting different from the original 
> posting?)
> 
> On Sun 10/Sep/2023 18:44:00 +0200 Jesse Thompson wrote:
> > 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.
> 
> 
> These look like aggregate data that could be included in DMARC reports or
> extensions thereof.  Perhaps that tool has more traction than 6651.
> 
> 
> Best
> Ale
> --
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-
> dkim__;!!CQl3mcHX2A!CxerxXN6Fi9wzANlOVjp2kI_Ez9FcMicLCLiN2yFF_BlGeekE
> KXeoaz9OSMOGVYMO6TL336wKx3HWNHUS6c$
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

2023-09-15 Thread Alessandro Vesely 

On Sun 10/Sep/2023 18:44:00 +0200 Jesse Thompson wrote:

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.



These look like aggregate data that could be included in DMARC reports or 
extensions thereof.  Perhaps that tool has more traction than 6651.



Best
Ale
--








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

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

2023-09-10 Thread 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 ] 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