Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/17/23 4:51 PM, Evan Burke wrote:



On Fri, Feb 17, 2023 at 9:49 AM Michael Thomas  wrote:


Which brings up another question which is applicable to the problem
statement: are mailbox providers like gmail, hotmail, etc getting
abused
from these replays? Some spam from whokn...@hotmail.com doesn't seem
like a very good address from arriving spam. For that matter, do bulk
senders even allow their domain to be the From domain? It seems
like a
pretty easy way to not affect their reputation is to require that the
mail be sent in the name of somebody else's domain.


There's a good amount of bulk mail sent with d= that doesn't match the 
visible From domain. Those signatures are typically used for DKIM 
based complaint feedback loops, and because they grant reputation to 
"mom" non-technical customers who either don't own a domain or 
haven't set up DKIM yet.  That DKIM d= domain has reputation on its 
own, independent from the visible From domain reputation.


That's a good point about just signing it with your own domain's key. 
I've been looking at some of my marketing mail and it looks like that's 
relatively common.


Seems like a tradeoff of ease of deployment vs. being a mark for 
spammers. Of course mom and pop's domain will likely have little 
reputation, but some of the mail I looked at were plenty big enough to 
develop their own reputation. This is of course mostly a business domain 
problem which this wg can't really say much about.




While I'm sure some replay spam is sent where there is a match between 
these two domains, it's entirely possible that attackers tend to 
prefer unaligned signatures, because that prevents the replay spam 
from showing on DMARC reporting for the d= domain being replayed.


Which, of course, you are free to say no to that.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Sun, Feb 19, 2023 at 11:49 AM Dave Crocker  wrote:

> This is a very basic point about protocols vs. implementations. A
> protocol defines the 4 walls of its sandbox.  It owns that sandbox and
> defines whatever it needs to, within the confines of that space.
>
> [...]
>
> But again, this is protocol and standards 101.  Seems odd to be
> rehashing something this basic, in a forum like this
>

I didn't see this as a rehashing, just a clarification of the nomenclature
being used.  Reviewing the last few posts in this thread have me thinking
we're all otherwise agreeing.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

The RFC just talks about returning PERFMAIL when the evaluation fails 
for one reason or another.  It's abstract, of course; the implementer 
is free to decide what that actually means in each case.  In the 
implementation I did, the library receives all the details and returns 
a status (with its own detail) about each signature, and the caller is 
free to do what it wants with that information.



This is a very basic point about protocols vs. implementations. A 
protocol defines the 4 walls of its sandbox.  It owns that sandbox and 
defines whatever it needs to, within the confines of that space.


To be reliable and accurate, it has to be objective and precise. 
Specific inputs, specific outputs.  It might distinguish permanent 
failures, such as a cryptographic value not validating -- the passage of 
time is not going to change that; versus a temporary failure, such as a 
failure to get a DNS response; the passage of time might change that.  
The liberal-vs-strict cliche applies to the interpretation of protocol 
specification details that might legitimately permit alternative 
interpretations, because prose can be ambiguous, in spite of efforts for 
it not to be.


But a protocol spec is not supposed to call on subjective judgement -- 
ie, whim.


An implementation of the protocol, also has no freedom, in terms of 
strict conformance.


However a real-world implementation, in which the protocol 
implementation is incorporated as a part, will tend to demonstrate all 
sorts of programmer and organization whim in deciding what to /do/ with 
the available information.  DKIM is precise.  A filtering engine that 
uses it well might not be.  Heuristics don't belong in a protocol spec 
but usually /do/ belong in a filtering engine.


But again, this is protocol and standards 101.  Seems odd to be 
rehashing something this basic, in a forum like this


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/18/23 8:41 PM, Murray S. Kucherawy wrote:

On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas  wrote:




Beyond this SHOULD, I think we need to consider whether the
caller needs to be told specifically when a failure occurs
for this reason.  Right now an implementation might return
just a PERMFAIL without noting that it's because of "x="
versus the signature failing for some other reason.  Should
the caller be given this extra detail to enhance the
decision tree, or will this just complicate things?


Why would it permfail? Does it permfail email without a
signature too?

Absent p=reject, there is nothing wrong with unsigned email.


I'm using the language of the DKIM RFC, so "PERMFAIL" here refers
to evaluation of the signature, not of the message.


But DKIM doesn't return status to anybody. That's completely
internal to the verifier. At most they might want to create an
A-R, but that isn't required and it's definitely not sent back to
the sender.

I think we're talking about different layers here. Otherwise, DKIM has 
to return status someplace, otherwise why do the evaluation?  That 
status might be in the form of an A-R header field, or a recommended 
final action, or a log entry, or whatever that operator wants.


The RFC just talks about returning PERFMAIL when the evaluation fails 
for one reason or another.  It's abstract, of course; the implementer 
is free to decide what that actually means in each case.  In the 
implementation I did, the library receives all the details and returns 
a status (with its own detail) about each signature, and the caller is 
free to do what it wants with that information.


From the standards standpoint a signature either verifies or not 
(modulo DNS glitches), but from a verifier's standpoint signatures and 
the covered parts of the message contains a wealth of other information 
that a filter module could use as inputs to make its decisions. That may 
or may not be distilled into a single status, but that is completely up 
to the receiver so PERMFAIL is just conceptual, not real.  x= in 
particular is rather vague about what a receiver should make of an 
expired signature, and completely silent on what a low value might 
imply. I've always thought of it as "I don't take responsibility for 
this anymore" from the sender's standpoint, but others are free to have 
a different opinion and that's fine (in particular, the HER EMAILS crowd 
certainly wouldn't care).


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas  wrote:

>
>
>> Beyond this SHOULD, I think we need to consider whether the caller needs
>> to be told specifically when a failure occurs for this reason.  Right now
>> an implementation might return just a PERMFAIL without noting that it's
>> because of "x=" versus the signature failing for some other reason.  Should
>> the caller be given this extra detail to enhance the decision tree, or will
>> this just complicate things?
>>
>> Why would it permfail? Does it permfail email without a signature too?
>>
>> Absent p=reject, there is nothing wrong with unsigned email.
>>
>
> I'm using the language of the DKIM RFC, so "PERMFAIL" here refers to
> evaluation of the signature, not of the message.
>
> But DKIM doesn't return status to anybody. That's completely internal to
> the verifier. At most they might want to create an A-R, but that isn't
> required and it's definitely not sent back to the sender.
>
I think we're talking about different layers here.  Otherwise, DKIM has to
return status someplace, otherwise why do the evaluation?  That status
might be in the form of an A-R header field, or a recommended final action,
or a log entry, or whatever that operator wants.

The RFC just talks about returning PERFMAIL when the evaluation fails for
one reason or another.  It's abstract, of course; the implementer is free
to decide what that actually means in each case.  In the implementation I
did, the library receives all the details and returns a status (with its
own detail) about each signature, and the caller is free to do what it
wants with that information.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/18/23 8:13 PM, Murray S. Kucherawy wrote:

On Sat, Feb 18, 2023 at 12:10 PM Michael Thomas  wrote:




Beyond this SHOULD, I think we need to consider whether the
caller needs to be told specifically when a failure occurs for
this reason.  Right now an implementation might return just a
PERMFAIL without noting that it's because of "x=" versus the
signature failing for some other reason.  Should the caller be
given this extra detail to enhance the decision tree, or will
this just complicate things?


Why would it permfail? Does it permfail email without a signature too?

Absent p=reject, there is nothing wrong with unsigned email.


I'm using the language of the DKIM RFC, so "PERMFAIL" here refers to 
evaluation of the signature, not of the message.


But DKIM doesn't return status to anybody. That's completely internal to 
the verifier. At most they might want to create an A-R, but that isn't 
required and it's definitely not sent back to the sender.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Sat, Feb 18, 2023 at 12:10 PM Michael Thomas  wrote:

>
>
> Beyond this SHOULD, I think we need to consider whether the caller needs
> to be told specifically when a failure occurs for this reason.  Right now
> an implementation might return just a PERMFAIL without noting that it's
> because of "x=" versus the signature failing for some other reason.  Should
> the caller be given this extra detail to enhance the decision tree, or will
> this just complicate things?
>
> Why would it permfail? Does it permfail email without a signature too?
>
> Absent p=reject, there is nothing wrong with unsigned email.
>

I'm using the language of the DKIM RFC, so "PERMFAIL" here refers to
evaluation of the signature, not of the message.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/17/23 5:02 PM, Murray S. Kucherawy wrote:
On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman 
 wrote:


Currently RFC 6376 says, "Signatures MAY be considered invalid". 
I think the practical effect as described in protocol terms would
be to change the MAY to SHOULD under X conditions and SHOULD NOT
under !X conditions.  Not that I'd expect to see this appear in a
protocol document (maybe some kind of applicability statement).


Beyond this SHOULD, I think we need to consider whether the caller 
needs to be told specifically when a failure occurs for this reason.  
Right now an implementation might return just a PERMFAIL without 
noting that it's because of "x=" versus the signature failing for some 
other reason.  Should the caller be given this extra detail to enhance 
the decision tree, or will this just complicate things?



Why would it permfail? Does it permfail email without a signature too?

Absent p=reject, there is nothing wrong with unsigned email.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

100% agree.  If this is the path we decide to go down, we can't really change 
the protocol for this.  It's advice on when/why to deal with X in a particular 
way.  Perhaps I was overly subtle, but that's why I described it as the 
practical effect.  I didn't mean to suggest a protocol change.

Scott K

On February 18, 2023 7:52:42 PM UTC, Barry Leiba  
wrote:
>I think that changing this to SHOULD is the wrong approach.  An
>Applicability Statement might well give advice, possibly at the SHOULD
>level, that goes beyond this and discusses use cases, but the base
>protocol uses MAY for a good reason, and at the protocol level it
>should stay that way.
>
>Barry
>
>On Fri, Feb 17, 2023 at 8:02 PM Murray S. Kucherawy  
>wrote:
>>
>> On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman  
>> wrote:
>>>
>>> Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think 
>>> the practical effect as described in protocol terms would be to change the 
>>> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions.  Not 
>>> that I'd expect to see this appear in a protocol document (maybe some kind 
>>> of applicability statement).
>>
>>
>> Beyond this SHOULD, I think we need to consider whether the caller needs to 
>> be told specifically when a failure occurs for this reason.  Right now an 
>> implementation might return just a PERMFAIL without noting that it's because 
>> of "x=" versus the signature failing for some other reason.  Should the 
>> caller be given this extra detail to enhance the decision tree, or will this 
>> just complicate things?
>>
>> I think, for instance, libopendkim does identify the reason for the failure, 
>> but I'm not sure whether any consumers of that API make use of that detail 
>> beyond maybe logging it.
>>
>> -MSK
>
>___
>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] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/18/23 11:52 AM, Barry Leiba wrote:

I think that changing this to SHOULD is the wrong approach.  An
Applicability Statement might well give advice, possibly at the SHOULD
level, that goes beyond this and discusses use cases, but the base
protocol uses MAY for a good reason, and at the protocol level it
should stay that way.


I agree that it's water under the bridge. If receivers find utility in 
it, they will take advantage of it. Plus there are more dimensions to 
this on the receiver's side which have nothing to do with anything 
normative.


Mike

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Barry Leiba]

I think that changing this to SHOULD is the wrong approach.  An
Applicability Statement might well give advice, possibly at the SHOULD
level, that goes beyond this and discusses use cases, but the base
protocol uses MAY for a good reason, and at the protocol level it
should stay that way.

Barry

On Fri, Feb 17, 2023 at 8:02 PM Murray S. Kucherawy  wrote:
>
> On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman  
> wrote:
>>
>> Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think 
>> the practical effect as described in protocol terms would be to change the 
>> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions.  Not 
>> that I'd expect to see this appear in a protocol document (maybe some kind 
>> of applicability statement).
>
>
> Beyond this SHOULD, I think we need to consider whether the caller needs to 
> be told specifically when a failure occurs for this reason.  Right now an 
> implementation might return just a PERMFAIL without noting that it's because 
> of "x=" versus the signature failing for some other reason.  Should the 
> caller be given this extra detail to enhance the decision tree, or will this 
> just complicate things?
>
> I think, for instance, libopendkim does identify the reason for the failure, 
> but I'm not sure whether any consumers of that API make use of that detail 
> beyond maybe logging it.
>
> -MSK

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman 
wrote:

> Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think
> the practical effect as described in protocol terms would be to change the
> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions.  Not
> that I'd expect to see this appear in a protocol document (maybe some kind
> of applicability statement).
>

Beyond this SHOULD, I think we need to consider whether the caller needs to
be told specifically when a failure occurs for this reason.  Right now an
implementation might return just a PERMFAIL without noting that it's
because of "x=" versus the signature failing for some other reason.  Should
the caller be given this extra detail to enhance the decision tree, or will
this just complicate things?

I think, for instance, libopendkim does identify the reason for the
failure, but I'm not sure whether any consumers of that API make use of
that detail beyond maybe logging it.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Fri, Feb 17, 2023 at 9:49 AM Michael Thomas  wrote:

>
> Which brings up another question which is applicable to the problem
> statement: are mailbox providers like gmail, hotmail, etc getting abused
> from these replays? Some spam from whokn...@hotmail.com doesn't seem
> like a very good address from arriving spam. For that matter, do bulk
> senders even allow their domain to be the From domain? It seems like a
> pretty easy way to not affect their reputation is to require that the
> mail be sent in the name of somebody else's domain.
>

There's a good amount of bulk mail sent with d= that doesn't match the
visible From domain. Those signatures are typically used for DKIM based
complaint feedback loops, and because they grant reputation to "mom"
non-technical customers who either don't own a domain or haven't set up
DKIM yet.  That DKIM d= domain has reputation on its own, independent from
the visible From domain reputation.

While I'm sure some replay spam is sent where there is a match between
these two domains, it's entirely possible that attackers tend to prefer
unaligned signatures, because that prevents the replay spam from showing on
DMARC reporting for the d= domain being replayed.

Taking Alessandro's idea a bit further with that fact in mind - what if we
had DMARC-style reporting specific to the d= domain? That could give us
useful data about where/when signatures are being used, and if/when they
are breaking.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/17/23 9:34 AM, Scott Kitterman wrote:

Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think the 
practical effect as described in protocol terms would be to change the MAY to SHOULD 
under X conditions and SHOULD NOT under !X conditions.  Not that I'd expect to see this 
appear in a protocol document (maybe some kind of applicability statement).

It does create a circumstance where indirect mail flows look inherently less 
good (since they take longer), which I don't like.  On the other hand, if X is 
set more than a minute or so in the future, mostly what is affected is mail 
that is delayed in transit, direct or indirect and maybe that's okay.


I think that the bulk senders who would be dialing down x= are not 
particularly worried about being sent through mailing lists.


Which brings up another question which is applicable to the problem 
statement: are mailbox providers like gmail, hotmail, etc getting abused 
from these replays? Some spam from whokn...@hotmail.com doesn't seem 
like a very good address from arriving spam. For that matter, do bulk 
senders even allow their domain to be the From domain? It seems like a 
pretty easy way to not affect their reputation is to require that the 
mail be sent in the name of somebody else's domain.


Mike

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think the 
practical effect as described in protocol terms would be to change the MAY to 
SHOULD under X conditions and SHOULD NOT under !X conditions.  Not that I'd 
expect to see this appear in a protocol document (maybe some kind of 
applicability statement).

It does create a circumstance where indirect mail flows look inherently less 
good (since they take longer), which I don't like.  On the other hand, if X is 
set more than a minute or so in the future, mostly what is affected is mail 
that is delayed in transit, direct or indirect and maybe that's okay.

Scott K

On February 17, 2023 5:22:37 PM UTC, "Murray S. Kucherawy" 
 wrote:
>On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba  wrote:
>
>> I like this approach: if the issue is that an "expired" signature is
>> treated as unsigned, I think we have an unacceptable level of false
>> positives.  But if the fact that a signature is valid but expired is
>> simply another factor in the decision, I think we might be OK, keeping
>> in mind that "x=" is purely advice to the validator.  To *really*
>> expire a signature, one has to stop publishing the key associated with
>> the selector.
>>
>
>One thing that would impede the success of this approach is whether current
>implementations make the distinction between "invalid" and "valid but
>expired", and for those that do not, how much churn and for how long it
>would take to make that change to the ecosystem.
>
>-MSK

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba  wrote:

> I like this approach: if the issue is that an "expired" signature is
> treated as unsigned, I think we have an unacceptable level of false
> positives.  But if the fact that a signature is valid but expired is
> simply another factor in the decision, I think we might be OK, keeping
> in mind that "x=" is purely advice to the validator.  To *really*
> expire a signature, one has to stop publishing the key associated with
> the selector.
>

One thing that would impede the success of this approach is whether current
implementations make the distinction between "invalid" and "valid but
expired", and for those that do not, how much churn and for how long it
would take to make that change to the ecosystem.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Alessandro Vesely]

On Thu 16/Feb/2023 21:56:52 +0100 Barry Leiba wrote:

Okay.  What's the value for X - T that prevents this problem, but doesn't cause DKIM 
signatures of "normal" mail to fail?


There's not one "right" value; we're talking about distributions
of timings for normal mail vs. replay, and yes, there's some
overlap there. In practice I've seen many signers choose
expirations in the range of 1hr to a few days.  1hr can be very
good at limiting the opportunity for high volume replay, but I
estimate "normal" signature breakage at that level is on the
order of 0.1%. 24hr is probably effectively zero breakage, but
with greater opportunity for replay.


I think you're way off on these numbers, especially for the 1-hour
case.  While normal circumstances get mail delivery in less than an
hour, I have seen *many* cases of legitimate mail delayed by hours --
sometimes quite a few hours.  I would consider anything less than two
days to be unacceptable, and with that sort of gap you don't do much
to prevent a spam blast.



Wouldn't it be possible to organize a gap-discovery scenario where the sender 
stores a per-user table of delivery times.  One could get timings from positive 
DSN when available.  Or one could create a new selector for each discovery, and 
measure the time between sending and the last DKIM key lookup.


For domains who re-sign before forwarding (perhaps using ARC), and are trusted 
by their forwardee, it can be enough to store a per-domain entry, which is much 
more practical.


It could be worth to add min/ max/ avg time entries to the  layout of 
aggregate DMARC reports.  (But this is the wrong mailing list to propose it.)



Best
Ale
--




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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Thu, Feb 16, 2023 at 3:32 PM Dave Crocker  wrote:

> On 2/16/2023 3:23 PM, Jeremy Harris wrote:
> > Does that not assume that the point where a message is held during
> > delay is after the point of signing?
>
> Yes, because it often and maybe nearly always is.  Even a single site
> can have multiple 'points' where processing of a message happens.
> Prepping and packaging a message would likely be done a long way before
> retry queuing happens.
>

Signing on each attempt is fairly common, at least among my peers. I think
this might just be because certain popular commercial MTA products do it
that way by default, and in practice it doesn't usually add enough load for
users to need to change the signing behavior.

In any case, it is an important distinction to make, and changes the
equation quite a bit for appropriate values of x=.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

On 2/16/2023 3:23 PM, Jeremy Harris wrote:
Does that not assume that the point where a message is held during 
delay is after the point of signing? 


Yes, because it often and maybe nearly always is.  Even a single site 
can have multiple 'points' where processing of a message happens.  
Prepping and packaging a message would likely be done a long way before 
retry queuing happens.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Jeremy Harris]

On 16/02/2023 23:17, Dave Crocker wrote:

On 2/16/2023 2:04 PM, Evan Burke wrote:

1hr is at the very low end of the scale, only appropriate in narrow, specific 
circumstances. I think you're right that 2+ days is the right range for most 
mail.


The historical common choice, for when to stop retrying mail delivery, has been 
3 days.  This was a matter of discussion some years ago and as I recall, was a 
comfortable choice.

And we got a note observing that  replay attack can reasonably begin within 
minutes of original posting.

This produces a choice for setting a timeout that is wholly ineffective or one 
that destroys retries of leigimate mail delivery attempts.


Does that not assume that the point where a message is held during delay is 
after the point of signing?
--
Cheers,
  Jeremy

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

On 2/16/2023 2:04 PM, Evan Burke wrote:
1hr is at the very low end of the scale, only appropriate in narrow, 
specific circumstances. I think you're right that 2+ days is the right 
range for most mail.


The historical common choice, for when to stop retrying mail delivery, 
has been 3 days.  This was a matter of discussion some years ago and as 
I recall, was a comfortable choice.


And we got a note observing that  replay attack can reasonably begin 
within minutes of original posting.


This produces a choice for setting a timeout that is wholly ineffective 
or one that destroys retries of leigimate mail delivery attempts.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

This could apply to other things like over some rate limit threshold or the 
reputation based approach I suggested as well.  The key thing that's relevant 
to the problem statement is that the problem is how the reputation impact of 
the signature is applied, not signature continues to validate after replay.

Scott K

On February 16, 2023 10:13:03 PM UTC, Barry Leiba  
wrote:
>I like this approach: if the issue is that an "expired" signature is
>treated as unsigned, I think we have an unacceptable level of false
>positives.  But if the fact that a signature is valid but expired is
>simply another factor in the decision, I think we might be OK, keeping
>in mind that "x=" is purely advice to the validator.  To *really*
>expire a signature, one has to stop publishing the key associated with
>the selector.
>
>Barry
>
>On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman  
>wrote:
>>
>>
>>
>> On February 16, 2023 9:21:51 PM UTC, Michael Thomas  wrote:
>> >
>> >On 2/16/23 12:56 PM, Barry Leiba wrote:
>>  Okay.  What's the value for X - T that prevents this problem, but 
>>  doesn't cause DKIM signatures of "normal" mail to fail?
>> >>> There's not one "right" value; we're talking about distributions
>> >>> of timings for normal mail vs. replay, and yes, there's some
>> >>> overlap there. In practice I've seen many signers choose
>> >>> expirations in the range of 1hr to a few days.  1hr can be very
>> >>> good at limiting the opportunity for high volume replay, but I
>> >>> estimate "normal" signature breakage at that level is on the
>> >>> order of 0.1%. 24hr is probably effectively zero breakage, but
>> >>> with greater opportunity for replay.
>> >> I think you're way off on these numbers, especially for the 1-hour
>> >> case.  While normal circumstances get mail delivery in less than an
>> >> hour, I have seen *many* cases of legitimate mail delayed by hours --
>> >> sometimes quite a few hours.  I would consider anything less than two
>> >> days to be unacceptable, and with that sort of gap you don't do much
>> >> to prevent a spam blast.
>> >
>> >I dunno, I would think it has to do with how much of a boost reputation is 
>> >actually giving deliverability. For typical marketing email that's not too 
>> >spammy maybe it doesn't make much difference? Adding signatures and a SPF 
>> >record is pretty easy to do these days, so it's sort of a no-brainer to 
>> >just do it. But if some small percentage with slow delivery fall through 
>> >the cracks, how adverse is that to delivery, assuming they don't have a 
>> >p=reject policy? That seems like it should be a pretty measurable thing for 
>> >an ESP.
>> >
>> >Sounds like something that Evan might know. Actually it might well be worth 
>> >adding that kind of estimate to the problem statement to judge how much of 
>> >a problem it is. What we have now is very hand waving and makes it 
>> >impossible to judge about how heroic we need to be.
>>
>> I think this highlights a key consideration that's easy to forget.  
>> Ultimately the issue is not that a 'bad' message was delivered, but that a 
>> 'bad' message got the benefit of whatever positive reputation was provided 
>> by the signature.  If one decides under X circumstances we will ignore a 
>> DKIM signature for Y purposes, then the negative impact of that is far less 
>> than that associated with rejecting the message, so we can probably tolerate 
>> more false positives.
>>
>> Scott K
>>
>> ___
>> 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

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Barry Leiba]

I like this approach: if the issue is that an "expired" signature is
treated as unsigned, I think we have an unacceptable level of false
positives.  But if the fact that a signature is valid but expired is
simply another factor in the decision, I think we might be OK, keeping
in mind that "x=" is purely advice to the validator.  To *really*
expire a signature, one has to stop publishing the key associated with
the selector.

Barry

On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman  wrote:
>
>
>
> On February 16, 2023 9:21:51 PM UTC, Michael Thomas  wrote:
> >
> >On 2/16/23 12:56 PM, Barry Leiba wrote:
>  Okay.  What's the value for X - T that prevents this problem, but 
>  doesn't cause DKIM signatures of "normal" mail to fail?
> >>> There's not one "right" value; we're talking about distributions
> >>> of timings for normal mail vs. replay, and yes, there's some
> >>> overlap there. In practice I've seen many signers choose
> >>> expirations in the range of 1hr to a few days.  1hr can be very
> >>> good at limiting the opportunity for high volume replay, but I
> >>> estimate "normal" signature breakage at that level is on the
> >>> order of 0.1%. 24hr is probably effectively zero breakage, but
> >>> with greater opportunity for replay.
> >> I think you're way off on these numbers, especially for the 1-hour
> >> case.  While normal circumstances get mail delivery in less than an
> >> hour, I have seen *many* cases of legitimate mail delayed by hours --
> >> sometimes quite a few hours.  I would consider anything less than two
> >> days to be unacceptable, and with that sort of gap you don't do much
> >> to prevent a spam blast.
> >
> >I dunno, I would think it has to do with how much of a boost reputation is 
> >actually giving deliverability. For typical marketing email that's not too 
> >spammy maybe it doesn't make much difference? Adding signatures and a SPF 
> >record is pretty easy to do these days, so it's sort of a no-brainer to just 
> >do it. But if some small percentage with slow delivery fall through the 
> >cracks, how adverse is that to delivery, assuming they don't have a p=reject 
> >policy? That seems like it should be a pretty measurable thing for an ESP.
> >
> >Sounds like something that Evan might know. Actually it might well be worth 
> >adding that kind of estimate to the problem statement to judge how much of a 
> >problem it is. What we have now is very hand waving and makes it impossible 
> >to judge about how heroic we need to be.
>
> I think this highlights a key consideration that's easy to forget.  
> Ultimately the issue is not that a 'bad' message was delivered, but that a 
> 'bad' message got the benefit of whatever positive reputation was provided by 
> the signature.  If one decides under X circumstances we will ignore a DKIM 
> signature for Y purposes, then the negative impact of that is far less than 
> that associated with rejecting the message, so we can probably tolerate more 
> false positives.
>
> Scott K
>
> ___
> 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] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Thu, Feb 16, 2023 at 12:57 PM Barry Leiba 
wrote:

> >> Okay.  What's the value for X - T that prevents this problem, but
> doesn't cause DKIM signatures of "normal" mail to fail?
> >
> > There's not one "right" value; we're talking about distributions
> > of timings for normal mail vs. replay, and yes, there's some
> > overlap there. In practice I've seen many signers choose
> > expirations in the range of 1hr to a few days.  1hr can be very
> > good at limiting the opportunity for high volume replay, but I
> > estimate "normal" signature breakage at that level is on the
> > order of 0.1%. 24hr is probably effectively zero breakage, but
> > with greater opportunity for replay.
>
> I think you're way off on these numbers, especially for the 1-hour
> case.  While normal circumstances get mail delivery in less than an
> hour, I have seen *many* cases of legitimate mail delayed by hours --
> sometimes quite a few hours.  I would consider anything less than two
> days to be unacceptable, and with that sort of gap you don't do much
> to prevent a spam blast.
>

Ok, this is an estimate based on a subset of our delivery data, and you
have a point that some senders/signers are going to deliver much slower
than we do. I'm certainly not globally authoritative on that.

1hr is at the very low end of the scale, only appropriate in narrow,
specific circumstances. I think you're right that 2+ days is the right
range for most mail.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 16, 2023 9:21:51 PM UTC, Michael Thomas  wrote:
>
>On 2/16/23 12:56 PM, Barry Leiba wrote:
 Okay.  What's the value for X - T that prevents this problem, but doesn't 
 cause DKIM signatures of "normal" mail to fail?
>>> There's not one "right" value; we're talking about distributions
>>> of timings for normal mail vs. replay, and yes, there's some
>>> overlap there. In practice I've seen many signers choose
>>> expirations in the range of 1hr to a few days.  1hr can be very
>>> good at limiting the opportunity for high volume replay, but I
>>> estimate "normal" signature breakage at that level is on the
>>> order of 0.1%. 24hr is probably effectively zero breakage, but
>>> with greater opportunity for replay.
>> I think you're way off on these numbers, especially for the 1-hour
>> case.  While normal circumstances get mail delivery in less than an
>> hour, I have seen *many* cases of legitimate mail delayed by hours --
>> sometimes quite a few hours.  I would consider anything less than two
>> days to be unacceptable, and with that sort of gap you don't do much
>> to prevent a spam blast.
>
>I dunno, I would think it has to do with how much of a boost reputation is 
>actually giving deliverability. For typical marketing email that's not too 
>spammy maybe it doesn't make much difference? Adding signatures and a SPF 
>record is pretty easy to do these days, so it's sort of a no-brainer to just 
>do it. But if some small percentage with slow delivery fall through the 
>cracks, how adverse is that to delivery, assuming they don't have a p=reject 
>policy? That seems like it should be a pretty measurable thing for an ESP.
>
>Sounds like something that Evan might know. Actually it might well be worth 
>adding that kind of estimate to the problem statement to judge how much of a 
>problem it is. What we have now is very hand waving and makes it impossible to 
>judge about how heroic we need to be.

I think this highlights a key consideration that's easy to forget.  Ultimately 
the issue is not that a 'bad' message was delivered, but that a 'bad' message 
got the benefit of whatever positive reputation was provided by the signature.  
If one decides under X circumstances we will ignore a DKIM signature for Y 
purposes, then the negative impact of that is far less than that associated 
with rejecting the message, so we can probably tolerate more false positives.

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/16/23 12:56 PM, Barry Leiba wrote:

Okay.  What's the value for X - T that prevents this problem, but doesn't cause DKIM 
signatures of "normal" mail to fail?

There's not one "right" value; we're talking about distributions
of timings for normal mail vs. replay, and yes, there's some
overlap there. In practice I've seen many signers choose
expirations in the range of 1hr to a few days.  1hr can be very
good at limiting the opportunity for high volume replay, but I
estimate "normal" signature breakage at that level is on the
order of 0.1%. 24hr is probably effectively zero breakage, but
with greater opportunity for replay.

I think you're way off on these numbers, especially for the 1-hour
case.  While normal circumstances get mail delivery in less than an
hour, I have seen *many* cases of legitimate mail delayed by hours --
sometimes quite a few hours.  I would consider anything less than two
days to be unacceptable, and with that sort of gap you don't do much
to prevent a spam blast.


I dunno, I would think it has to do with how much of a boost reputation 
is actually giving deliverability. For typical marketing email that's 
not too spammy maybe it doesn't make much difference? Adding signatures 
and a SPF record is pretty easy to do these days, so it's sort of a 
no-brainer to just do it. But if some small percentage with slow 
delivery fall through the cracks, how adverse is that to delivery, 
assuming they don't have a p=reject policy? That seems like it should be 
a pretty measurable thing for an ESP.


Sounds like something that Evan might know. Actually it might well be 
worth adding that kind of estimate to the problem statement to judge how 
much of a problem it is. What we have now is very hand waving and makes 
it impossible to judge about how heroic we need to be.


Mike


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

There's not one "right" value; we're talking about distributions of 
timings for normal mail vs. replay, and yes, there's some overlap there.

...
I understand the pushback; this is a list to talk about a standard, 
and standards tend to be a lot more binary in their functionality,



Glad to see the challenge of using x= characterized here.  I suggest two 
points that probably need considering:


1., Realistic, real-world examples where the proposed mechanism is known 
to work and to work well.  The idea that it is possible to have 
signature expiration be short enough to be useful against replay, 
without destroying DKIM's primary use, does not seem even slightly 
realistic to me.  So field demonstration of utility seems essential.


2. Moving heuristic advice to a discussion paper, rather than a 
technical specification.  There's nothing wrong with documenting things 
that someone, somewhere might find useful, but with caveat emptor 
warnings highlighted.  But no, those are not technical specifications.


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Barry Leiba]

>> Okay.  What's the value for X - T that prevents this problem, but doesn't 
>> cause DKIM signatures of "normal" mail to fail?
>
> There's not one "right" value; we're talking about distributions
> of timings for normal mail vs. replay, and yes, there's some
> overlap there. In practice I've seen many signers choose
> expirations in the range of 1hr to a few days.  1hr can be very
> good at limiting the opportunity for high volume replay, but I
> estimate "normal" signature breakage at that level is on the
> order of 0.1%. 24hr is probably effectively zero breakage, but
> with greater opportunity for replay.

I think you're way off on these numbers, especially for the 1-hour
case.  While normal circumstances get mail delivery in less than an
hour, I have seen *many* cases of legitimate mail delayed by hours --
sometimes quite a few hours.  I would consider anything less than two
days to be unacceptable, and with that sort of gap you don't do much
to prevent a spam blast.

Barry

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 16, 2023 8:03:01 PM UTC, Evan Burke  
wrote:
>On Thu, Feb 16, 2023 at 10:45 AM Scott Kitterman 
>wrote:
>
>>
>> On February 16, 2023 6:10:39 PM UTC, Evan Burke > 40mailchimp@dmarc.ietf.org> wrote:
>> >The biggest current problem with replay is that it happens in bulk, at
>> >substantial scale. x= is effective against that because it takes time to
>> >send millions of messages.  Is it perfect? No. But it's not difficult to
>> >choose between 10,000 replays using my domain vs. millions.
>>
>> Okay.  What's the value for X - T that prevents this problem, but doesn't
>> cause DKIM signatures of "normal" mail to fail?
>>
>>
>There's not one "right" value; we're talking about distributions of timings
>for normal mail vs. replay, and yes, there's some overlap there. In
>practice I've seen many signers choose expirations in the range of 1hr to a
>few days.  1hr can be very good at limiting the opportunity for high volume
>replay, but I estimate "normal" signature breakage at that level is on the
>order of 0.1%. 24hr is probably effectively zero breakage, but with greater
>opportunity for replay.
>
>I understand the pushback; this is a list to talk about a standard, and
>standards tend to be a lot more binary in their functionality, so to speak.
>Maybe you're not receptive to a more practical solution - that's fine, I
>respect that - but I think there may be others here who are more open to
>that kind of approach.

I'm not necessarily opposed to going down this kind of path, but it should be 
with eyes open on the side effects.  I'm all about practical, but in my book 
that includes not creating an attractive nuisance that causes more problems 
than it solves (not saying that X= is that, I don't have much of an opinion 
yet).

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Thu, Feb 16, 2023 at 10:45 AM Scott Kitterman 
wrote:

>
> On February 16, 2023 6:10:39 PM UTC, Evan Burke  40mailchimp@dmarc.ietf.org> wrote:
> >The biggest current problem with replay is that it happens in bulk, at
> >substantial scale. x= is effective against that because it takes time to
> >send millions of messages.  Is it perfect? No. But it's not difficult to
> >choose between 10,000 replays using my domain vs. millions.
>
> Okay.  What's the value for X - T that prevents this problem, but doesn't
> cause DKIM signatures of "normal" mail to fail?
>
>
There's not one "right" value; we're talking about distributions of timings
for normal mail vs. replay, and yes, there's some overlap there. In
practice I've seen many signers choose expirations in the range of 1hr to a
few days.  1hr can be very good at limiting the opportunity for high volume
replay, but I estimate "normal" signature breakage at that level is on the
order of 0.1%. 24hr is probably effectively zero breakage, but with greater
opportunity for replay.

I understand the pushback; this is a list to talk about a standard, and
standards tend to be a lot more binary in their functionality, so to speak.
Maybe you're not receptive to a more practical solution - that's fine, I
respect that - but I think there may be others here who are more open to
that kind of approach.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 16, 2023 6:10:39 PM UTC, Evan Burke 
 wrote:
>On Thu, Feb 16, 2023 at 7:30 AM Murray S. Kucherawy 
>wrote:
>
>>
>> If my prior formulation is right, i.e., that the attack only takes a few
>> seconds to complete, what "x=" value are we proposing that will work here
>> without also bringing undesirable side effects?
>>
>>
>The biggest current problem with replay is that it happens in bulk, at
>substantial scale. x= is effective against that because it takes time to
>send millions of messages.  Is it perfect? No. But it's not difficult to
>choose between 10,000 replays using my domain vs. millions.

Okay.  What's the value for X - T that prevents this problem, but doesn't cause 
DKIM signatures of "normal" mail to fail?

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Thu, Feb 16, 2023 at 7:30 AM Murray S. Kucherawy 
wrote:

>
> If my prior formulation is right, i.e., that the attack only takes a few
> seconds to complete, what "x=" value are we proposing that will work here
> without also bringing undesirable side effects?
>
>
The biggest current problem with replay is that it happens in bulk, at
substantial scale. x= is effective against that because it takes time to
send millions of messages.  Is it perfect? No. But it's not difficult to
choose between 10,000 replays using my domain vs. millions.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

On 2/16/2023 2:39 AM, Laura Atkins wrote:
The flip side of that is that spammers are not equal opportunity: they 
target the large consumer mailbox providers. So if the problem only 
affects groups that are this tall, then a solution that fixes it for 
those providers might be reasonable. 


This nicely imposes an initial requirement to formulate the concrete 
details of the height requirement, in a fashion that permits reasonably 
objective, reliable application for determining whether they are 
appropriate for the ride.


Who is the spec intended for, exactly, and how can they tell, reliably 
an accurately, that they are in the target market?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Wed, Feb 15, 2023 at 10:49 PM Evan Burke 
wrote:

>
>> I don't think we're saying different things.  I remember the point of the
>> answer I got in that session being that most, but not all, implementations
>> check or enforce signature expiration.  But that means if "x=" is the
>> solution we land on, we have to accept that a possibly-significant part of
>> the ecosystem won't be able to use that solution.
>>
>> Then again, anything new we roll out is going to take a while to become
>> universal anyway.
>>
>
> The short version is that x= works where it matters at the moment. As far
> as I've seen and heard from others, DKIM replay spam currently focuses
> heavily on replaying to recipients at just a few of the top 10 global
> mailbox providers. This is for reasons of economies of scale - roughly
> speaking, it might be viable to spend 1000 hours finding a way through the
> filters of a provider operating 200 million mailboxes, where it is not for
> a provider hosting 20 million. This is part of why I don't think we'll see
> replay attacks expand significantly to more domains; replay is just one
> ingredient in a larger spam recipe that takes a lot of other fine-tuning to
> achieve its intended effect.
>

If my prior formulation is right, i.e., that the attack only takes a few
seconds to complete, what "x=" value are we proposing that will work here
without also bringing undesirable side effects?

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Laura Atkins]

> On 16 Feb 2023, at 04:16, Murray S. Kucherawy  wrote:
>> 
>> There are *tons* of external dependencies on the filtering MTA. I really 
>> can't imagine that this would be the straw that breaks the   camel's 
>> back.
> 
> Depends (as I think Scott said) on the size and resources available to the 
> operator, and how much they're a target of this attack.  We've generally 
> shied away in the past from solutions of the form "you have to be at least 
> this tall to play".

The flip side of that is that spammers are not equal opportunity: they target 
the large consumer mailbox providers. So if the problem only affects groups 
that are this tall, then a solution that fixes it for those providers might be 
reasonable. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Wed, Feb 15, 2023 at 8:16 PM Murray S. Kucherawy 
wrote:

> On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas  wrote:
>
>>
>> There's also the question of whether "x=" is properly enforced.  RFC 6376
>> says verifiers "MAY" choose to enforce it.  I think I asked about this at a
>> conference recently and was told that it's not universally supported by
>> implementations.
>>
>> Others have said that the enforcement is pretty good. But I have no way
>> to evaluate if that's true.
>>
>
> I don't think we're saying different things.  I remember the point of the
> answer I got in that session being that most, but not all, implementations
> check or enforce signature expiration.  But that means if "x=" is the
> solution we land on, we have to accept that a possibly-significant part of
> the ecosystem won't be able to use that solution.
>
> Then again, anything new we roll out is going to take a while to become
> universal anyway.
>

The short version is that x= works where it matters at the moment. As far
as I've seen and heard from others, DKIM replay spam currently focuses
heavily on replaying to recipients at just a few of the top 10 global
mailbox providers. This is for reasons of economies of scale - roughly
speaking, it might be viable to spend 1000 hours finding a way through the
filters of a provider operating 200 million mailboxes, where it is not for
a provider hosting 20 million. This is part of why I don't think we'll see
replay attacks expand significantly to more domains; replay is just one
ingredient in a larger spam recipe that takes a lot of other fine-tuning to
achieve its intended effect.

This has implications for rollout as well. I think the ideal solution would
enable affected signers/verifiers to deal with the problem, while everyone
else can ignore it entirely (until/unless they do see a problem). I think a
count-based approach could do exactly that.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas  wrote:

>
> There's also the question of whether "x=" is properly enforced.  RFC 6376
> says verifiers "MAY" choose to enforce it.  I think I asked about this at a
> conference recently and was told that it's not universally supported by
> implementations.
>
> Others have said that the enforcement is pretty good. But I have no way to
> evaluate if that's true.
>

I don't think we're saying different things.  I remember the point of the
answer I got in that session being that most, but not all, implementations
check or enforce signature expiration.  But that means if "x=" is the
solution we land on, we have to accept that a possibly-significant part of
the ecosystem won't be able to use that solution.

Then again, anything new we roll out is going to take a while to become
universal anyway.

> Going the route of some kind of duplicate signature detection alleviates
> the risk of that approach, but also sort of inverts it: If you assume each
> signature will only appear once, there's a window during which the first
> signature works, and then a second window during which duplicates will be
> blocked, but then that process recycles when the cache expires.  That could
> mean replays work if I just out-wait your cache.  You also introduce the
> risk of false positives, where a legitimate message tries to arrive in
> separate envelopes with the same signature, and all but the first one get
> blocked.
>
> I would imagine that the cache should be valid for a small x= expiry.
> That's really a tuning problem on the sending domain.
>
Possibly.  I get the impression that a good chunk of the industry would
like something more from us than "you have to tune this" (i.e., something
laying out specific values), but maybe we can't do anything beyond general
advice because there are too many other variables at play.  RFC 6647
avoided laying out specific values for greylisting, for example.

> There are *tons* of external dependencies on the filtering MTA. I really
> can't imagine that this would be the straw that breaks the camel's back.
>

Depends (as I think Scott said) on the size and resources available to the
operator, and how much they're a target of this attack.  We've generally
shied away in the past from solutions of the form "you have to be at least
this tall to play".

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 15, 2023 10:18:50 PM UTC, "Murray S. Kucherawy" 
 wrote:
>On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman 
>wrote:
>
>> Any reputation based solution does have down scale limits.  Small mail
>> sources
>> (such as your random Nebraska forwarder) generally will have no reputation
>> vice a negative one and so wouldn't get penalized in a scheme like the one
>> I
>> suggested.  This does, however, highlight where the performance challenge
>> is.
>> We've moved it from duplicate detection to rapid assessment of reputation
>> for
>> hosts that have sudden volume increases.
>>
>
>I wonder if this could be separated into "reputation" and "hosts that have
>sudden volume increases".
>
>Reputation is hard.  Large operators spend a lot of R time coming up with
>algorithms that accurately (for some value thereof) compute the reputation
>it should associate with an identity.  That investment means they're not
>inclined to share that secret sauce.  Small operators without those
>resources long for an open source solution, or a cheap or free service from
>which they can reliably get reputation data.  Companies that offer
>reputation data for public consumption have been sued out of existence by
>people that get marked as suspect, so really good ones don't seem to abound
>last I checked.
>
>There's a lot less secret sauce involved in the latter.  It would be
>interesting to see if some simple recordkeeping of this nature could make a
>dent in the problem space we're discussing.  But that might just encourage
>further distribution of the attack to avoid detection.

I think it could, but it has its own scaling problems.

Further distribution has two sides:

If I have multiple hosts (for any of the many reasons one does) and the 
attacker hits all of them with some fraction of the attack volume, that doesn't 
materially increase the cost of the attack.

If I can rapidly share rate data among my hosts so that distributing volume 
among them doesn't help avoid volume detection, then that either raises the 
cost of the attack (need more IP addresses to send from) or reduces it's 
effectiveness (messages blocked due to being over rate).  Either of those 
results are good things, but whatever the process is, it's no longer simple.

This is the flip side of reputation in a way.  Technically easy for small 
domains, but hugely harder at any significant scale.

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/15/23 2:12 PM, Murray S. Kucherawy wrote:

On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:

At maximum, isn't it just the x= value? It seems to me that if you
don't specify an x= value, or it's essentially infinite, they are
saying they don't care about "replays". Which is fine in most
cases and you can just ignore it. Something that really throttles
down x= should be a tractable problem, right?


Remember that the threat model is:

1) send a message through A to B, acquiring A's signature
2) collect the message from B
3) re-post the message to C, D, E, ...

These days, this attack is complete within seconds.  If you select an 
"x=" small enough to thwart this, you have to expect that all 
legitimate deliveries will happen even faster.  But email delivery can 
be slow for lots of legitimate reasons.  So I would argue that "x=" 
alone can't really solve this problem without introducing other 
constraints that we don't really want.


I'm not saying that it solves the problem, only that it bounds how much 
you'd need to store.





There's also the question of whether "x=" is properly enforced.  RFC 
6376 says verifiers "MAY" choose to enforce it.  I think I asked about 
this at a conference recently and was told that it's not universally 
supported by implementations.
Others have said that the enforcement is pretty good. But I have no way 
to evaluate if that's true.




Going the route of some kind of duplicate signature detection 
alleviates the risk of that approach, but also sort of inverts it: If 
you assume each signature will only appear once, there's a window 
during which the first signature works, and then a second window 
during which duplicates will be blocked, but then that process 
recycles when the cache expires.  That could mean replays work if I 
just out-wait your cache.  You also introduce the risk of false 
positives, where a legitimate message tries to arrive in separate 
envelopes with the same signature, and all but the first one get blocked.


I would imagine that the cache should be valid for a small x= expiry. 
That's really a tuning problem on the sending domain.


But I mentioned in another response that if you detect lots of replays 
and could turn up the dial on your spam filters, that may well thwart a 
sizable amount of spam *and* have the ability to be retroactive with 
spam that has made it past the filter.



But even at scale it seems like a pretty small database in
comparison to the overall volume. It's would be easy for a
receiver to just prune it after a day or so, say.

It creates an additional external dependency on the SMTP server.  I 
guess you have to evaluate the cost of the database versus the cost of 
the protection it provides, and include reasonable advice about what 
to do when the database is not available.


There are *tons* of external dependencies on the filtering MTA. I really 
can't imagine that this would be the straw that breaks the camel's back.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman 
wrote:

> Any reputation based solution does have down scale limits.  Small mail
> sources
> (such as your random Nebraska forwarder) generally will have no reputation
> vice a negative one and so wouldn't get penalized in a scheme like the one
> I
> suggested.  This does, however, highlight where the performance challenge
> is.
> We've moved it from duplicate detection to rapid assessment of reputation
> for
> hosts that have sudden volume increases.
>

I wonder if this could be separated into "reputation" and "hosts that have
sudden volume increases".

Reputation is hard.  Large operators spend a lot of R time coming up with
algorithms that accurately (for some value thereof) compute the reputation
it should associate with an identity.  That investment means they're not
inclined to share that secret sauce.  Small operators without those
resources long for an open source solution, or a cheap or free service from
which they can reliably get reputation data.  Companies that offer
reputation data for public consumption have been sued out of existence by
people that get marked as suspect, so really good ones don't seem to abound
last I checked.

There's a lot less secret sauce involved in the latter.  It would be
interesting to see if some simple recordkeeping of this nature could make a
dent in the problem space we're discussing.  But that might just encourage
further distribution of the attack to avoid detection.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:

> At maximum, isn't it just the x= value? It seems to me that if you don't
> specify an x= value, or it's essentially infinite, they are saying they
> don't care about "replays". Which is fine in most cases and you can just
> ignore it. Something that really throttles down x= should be a tractable
> problem, right?
>

Remember that the threat model is:

1) send a message through A to B, acquiring A's signature
2) collect the message from B
3) re-post the message to C, D, E, ...

These days, this attack is complete within seconds.  If you select an "x="
small enough to thwart this, you have to expect that all legitimate
deliveries will happen even faster.  But email delivery can be slow for
lots of legitimate reasons.  So I would argue that "x=" alone can't really
solve this problem without introducing other constraints that we don't
really want.

There's also the question of whether "x=" is properly enforced.  RFC 6376
says verifiers "MAY" choose to enforce it.  I think I asked about this at a
conference recently and was told that it's not universally supported by
implementations.

Going the route of some kind of duplicate signature detection alleviates
the risk of that approach, but also sort of inverts it: If you assume each
signature will only appear once, there's a window during which the first
signature works, and then a second window during which duplicates will be
blocked, but then that process recycles when the cache expires.  That could
mean replays work if I just out-wait your cache.  You also introduce the
risk of false positives, where a legitimate message tries to arrive in
separate envelopes with the same signature, and all but the first one get
blocked.

> But even at scale it seems like a pretty small database in comparison to
> the overall volume. It's would be easy for a receiver to just prune it
> after a day or so, say.
>
It creates an additional external dependency on the SMTP server.  I guess
you have to evaluate the cost of the database versus the cost of the
protection it provides, and include reasonable advice about what to do when
the database is not available.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On Wednesday, February 15, 2023 5:23:34 AM EST Alessandro Vesely wrote:
> On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote:
> > On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote:
> >> On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:
> >>> On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:
>  Have you considered something like rate limiting on the receiver side
>  for
>  things with duplicate msg-id's? Aka, a tar pit, iirc?
> >> 
> >> I believe Yahoo does currently use some sort of count-based approach to
> >> detect replay, though I'm not clear on the details.
> >> 
>  As I recall that technique is sometimes not suggested because (a) we
>  can't
>  come up with good advice about how long you need to cache message IDs
>  to
>  watch for duplicates, and (b) the longer that cache needs to live, the
>  larger of a resource burden the technique imposes, and small operators
>  might not be able to do it well.
> >>> 
> >>> At maximum, isn't it just the x= value? It seems to me that if you don't
> >>> specify an x= value, or it's essentially infinite, they are saying they
> >>> don't care about "replays". Which is fine in most cases and you can just
> >>> ignore it. Something that really throttles down x= should be a tractable
> >>> problem, right?
> 
> The ration between duplicate count and x= is the spamming speed.
> 
> >>> But even at scale it seems like a pretty small database in comparison to
> >>> the overall volume. It's would be easy for a receiver to just prune it
> >>> after a day or so, say.
> >> 
> >> I think count-based approaches can be made even simpler than that, in
> >> fact.
> >> I'm halfway inclined to submit a draft using that approach, as time
> >> permits.> 
> > I suppose if the thresholds are high enough, it won't hit much in the way
> > of legitimate mail (as an example, I anticipate this message will hit at
> > least hundreds of mail boxes at Gmail, but not millions), but of course
> > letting the first X through isn't ideal.
> 
> Scott's message hit my server exactly once.  Counting is a no-op for small
> operators.
> 
> > If I had access to a database of numerically scored IP reputation values
> > (I
> > don't currently, but I have in the past, so I can imagine this at least),
> > I
> > think I'd be more inclined to look at the reputation of the domain as a
> > whole (something like average score of messages from an SPF validated
> > Mail From, DKIM validated d=, or DMARC pass domain) and the reputation of
> > the IP for a message from that domain and then if there was sufficient
> > statistical confidence that the reputation of the IP was "bad" compared
> > to the domain's reputation I would infer it was likely being replayed and
> > ignore the signature.
> Some random forwarder in Nebraska can be easily mistaken for a spammer that
> way.  Reputation is affected by email volume.  Even large operators have
> little knowledge of almost silent MTAs.
> 
> Having senders' signatures transmit the perceived risk of an author would
> contribute an additional evaluation factor here.  Rather than discard
> validated signatures, have an indication to weight them.  (In that respect,
> let me note the usage of ARC as a sort of second class DKIM, when the
> signer knows nothing about the author.)

Any reputation based solution does have down scale limits.  Small mail sources 
(such as your random Nebraska forwarder) generally will have no reputation 
vice a negative one and so wouldn't get penalized in a scheme like the one I 
suggested.  This does, however, highlight where the performance challenge is.  
We've moved it from duplicate detection to rapid assessment of reputation for 
hosts that have sudden volume increases.

I think that's fine as that's not at all a problem that's unique to this 
challenge and ultimately, I think if replay attacks end up more complicated 
because instead of blasting 1,000,000 messages from one host they have to 
trickle 1.000 messages from 1,000 hosts it's a win.

I don't think this is a problem that's going to have a singular mechanical 
solution to that makes it go away.  This is substantially about making this 
particular technique less effective so maybe they move on to something else or 
at least less bad stuff gets delivered.

> > I think that approaches the same effect as a "too many dupes" approach
> > without the threshold problem.  It does require reputation data, but I
> > assume any entity of a non-trivial size either has access to their own or
> > can buy it from someone else.
> 
> DNSWLs exist.

I'm not sure how that's relevant.  Please expand on this if you think it's 
important.

Scott K


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Alessandro Vesely]

On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote:

On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote:

On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:

On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:
Have you considered something like rate limiting on the receiver side for 
things with duplicate msg-id's? Aka, a tar pit, iirc?


I believe Yahoo does currently use some sort of count-based approach to 
detect replay, though I'm not clear on the details.


As I recall that technique is sometimes not suggested because (a) we can't 
come up with good advice about how long you need to cache message IDs to 
watch for duplicates, and (b) the longer that cache needs to live, the 
larger of a resource burden the technique imposes, and small operators 
might not be able to do it well.


At maximum, isn't it just the x= value? It seems to me that if you don't 
specify an x= value, or it's essentially infinite, they are saying they 
don't care about "replays". Which is fine in most cases and you can just 
ignore it. Something that really throttles down x= should be a tractable 
problem, right?



The ration between duplicate count and x= is the spamming speed.


But even at scale it seems like a pretty small database in comparison to 
the overall volume. It's would be easy for a receiver to just prune it 
after a day or so, say.


I think count-based approaches can be made even simpler than that, in fact. 
I'm halfway inclined to submit a draft using that approach, as time permits.


I suppose if the thresholds are high enough, it won't hit much in the way of 
legitimate mail (as an example, I anticipate this message will hit at least 
hundreds of mail boxes at Gmail, but not millions), but of course letting the 
first X through isn't ideal.



Scott's message hit my server exactly once.  Counting is a no-op for small 
operators.



If I had access to a database of numerically scored IP reputation values (I 
don't currently, but I have in the past, so I can imagine this at least), I 
think I'd be more inclined to look at the reputation of the domain as a whole 
(something like average score of messages from an SPF validated Mail From, 
DKIM validated d=, or DMARC pass domain) and the reputation of the IP for a 
message from that domain and then if there was sufficient statistical confidence 
that the reputation of the IP was "bad" compared to the domain's reputation I 
would infer it was likely being replayed and ignore the signature.



Some random forwarder in Nebraska can be easily mistaken for a spammer that 
way.  Reputation is affected by email volume.  Even large operators have little 
knowledge of almost silent MTAs.


Having senders' signatures transmit the perceived risk of an author would 
contribute an additional evaluation factor here.  Rather than discard validated 
signatures, have an indication to weight them.  (In that respect, let me note 
the usage of ARC as a sort of second class DKIM, when the signer knows nothing 
about the author.)



I think that approaches the same effect as a "too many dupes" approach without 
the threshold problem.  It does require reputation data, but I assume any 
entity of a non-trivial size either has access to their own or can buy it from 
someone else.



DNSWLs exist.


Best
Ale
--



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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote:
> On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:
> > On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:
> >> Have you considered something like rate limiting on the receiver side for
> >> things with duplicate msg-id's? Aka, a tar pit, iirc?
> 
> I believe Yahoo does currently use some sort of count-based approach to
> detect replay, though I'm not clear on the details.
> 
> > As I recall that technique is sometimes not suggested because (a) we can't
> > come up with good advice about how long you need to cache message IDs to
> > watch for duplicates, and (b) the longer that cache needs to live, the
> > larger of a resource burden the technique imposes, and small operators
> > might not be able to do it well.
> > 
> > At maximum, isn't it just the x= value? It seems to me that if you don't
> > specify an x= value, or it's essentially infinite, they are saying they
> > don't care about "replays". Which is fine in most cases and you can just
> > ignore it. Something that really throttles down x= should be a tractable
> > problem, right?
> > 
> > But even at scale it seems like a pretty small database in comparison to
> > the overall volume. It's would be easy for a receiver to just prune it
> > after a day or so, say.
> 
> I think count-based approaches can be made even simpler than that, in fact.
> I'm halfway inclined to submit a draft using that approach, as time permits.

I suppose if the thresholds are high enough, it won't hit much in the way of 
legitimate mail (as an example, I anticipate this message will hit at least 
hundreds of mail boxes at Gmail, but not millions), but of course letting the 
first X through isn't ideal.

If I had access to a database of numerically scored IP reputation values (I 
don't currently, but I have in the past, so I can imagine this at least), I 
think I'd be more inclined to look at the reputation of the domain as a whole 
(something like average score of messages from an SPF validated Mail From, 
DKIM validated d=, or DMARC pass domain) and the reputation of the IP for a 
message from that domain and then if there was sufficient statistical 
confidence 
that the reputation of the IP was "bad" compared to the domain's reputation I 
would infer it was likely being replayed and ignore the signature.

I think that approaches the same effect as a "too many dupes" approach without 
the threshold problem.  It does require reputation data, but I assume any 
entity of a non-trivial size either has access to their own or can buy it from 
someone else.

Scott K


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/14/23 1:16 PM, Evan Burke wrote:



On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:


On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas 
wrote:

Have you considered something like rate limiting on the
receiver side for things with duplicate msg-id's? Aka, a tar
pit, iirc?



I believe Yahoo does currently use some sort of count-based approach 
to detect replay, though I'm not clear on the details.




As I recall that technique is sometimes not suggested because (a)
we can't come up with good advice about how long you need to
cache message IDs to watch for duplicates, and (b) the longer
that cache needs to live, the larger of a resource burden the
technique imposes, and small operators might not be able to do it
well.


At maximum, isn't it just the x= value? It seems to me that if you
don't specify an x= value, or it's essentially infinite, they are
saying they don't care about "replays". Which is fine in most
cases and you can just ignore it. Something that really throttles
down x= should be a tractable problem, right?

But even at scale it seems like a pretty small database in
comparison to the overall volume. It's would be easy for a
receiver to just prune it after a day or so, say.


I think count-based approaches can be made even simpler than that, in 
fact. I'm halfway inclined to submit a draft using that approach, as 
time permits.


The problem draft mentions it, but if it's Yahoo doing it have they 
documented it? Or is this just hallway chatter, maybe?


One thing that occurs to me is that if filters can have knobs to dial up 
the sensitivity of detection (at risk of false positives), maybe that 
can be applied if you're seeing tons of dups. That would be especially 
frustrating to a spammer since they could get something through in the 
small only to be detected as spam when they are trying to exploit it.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:

> On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:
>
>> Have you considered something like rate limiting on the receiver side for
>> things with duplicate msg-id's? Aka, a tar pit, iirc?
>>
>
I believe Yahoo does currently use some sort of count-based approach to
detect replay, though I'm not clear on the details.

>
> As I recall that technique is sometimes not suggested because (a) we can't
> come up with good advice about how long you need to cache message IDs to
> watch for duplicates, and (b) the longer that cache needs to live, the
> larger of a resource burden the technique imposes, and small operators
> might not be able to do it well.
>
> At maximum, isn't it just the x= value? It seems to me that if you don't
> specify an x= value, or it's essentially infinite, they are saying they
> don't care about "replays". Which is fine in most cases and you can just
> ignore it. Something that really throttles down x= should be a tractable
> problem, right?
>
> But even at scale it seems like a pretty small database in comparison to
> the overall volume. It's would be easy for a receiver to just prune it
> after a day or so, say.
>

I think count-based approaches can be made even simpler than that, in fact.
I'm halfway inclined to submit a draft using that approach, as time permits.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/14/23 11:30 AM, Murray S. Kucherawy wrote:

On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:

Have you considered something like rate limiting on the receiver
side for things with duplicate msg-id's? Aka, a tar pit, iirc?


As I recall that technique is sometimes not suggested because (a) we 
can't come up with good advice about how long you need to cache 
message IDs to watch for duplicates, and (b) the longer that cache 
needs to live, the larger of a resource burden the technique imposes, 
and small operators might not be able to do it well.


At maximum, isn't it just the x= value? It seems to me that if you don't 
specify an x= value, or it's essentially infinite, they are saying they 
don't care about "replays". Which is fine in most cases and you can just 
ignore it. Something that really throttles down x= should be a tractable 
problem, right?


But even at scale it seems like a pretty small database in comparison to 
the overall volume. It's would be easy for a receiver to just prune it 
after a day or so, say.



And to be clear, what do you mean by "oversigning"? Is it
something different than just signing the Subject, etc, header in
the first place?

This was a term invented to refer to the technique described in 
Section 8.15 of RFC 6376.



Ok, thanks.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:

> Have you considered something like rate limiting on the receiver side for
> things with duplicate msg-id's? Aka, a tar pit, iirc?
>

As I recall that technique is sometimes not suggested because (a) we can't
come up with good advice about how long you need to cache message IDs to
watch for duplicates, and (b) the longer that cache needs to live, the
larger of a resource burden the technique imposes, and small operators
might not be able to do it well.

> And to be clear, what do you mean by "oversigning"? Is it something
> different than just signing the Subject, etc, header in the first place?
>
This was a term invented to refer to the technique described in Section
8.15 of RFC 6376.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/13/23 9:43 PM, Evan Burke wrote:



On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas  wrote:

On 2/10/23 2:10 PM, Evan Burke wrote:

The M3AAWG BCP will cover recommended header signing/oversigning
policies. I'll make sure that's shared here when it's published.


Any idea when that might drop?

I'll roughly summarize the guidance here for now. The primary audience 
for these recommendations is senders/signers with high volume shared 
signing domains; these domains are prime targets for replay because of 
their good reputation. Other approaches exist, but these are the ones 
that can generally be implemented relatively quickly.


- Screen new accounts based on industry standard methods
- Scan outbound mail for spam-like content, and restrict or block 
sending based on results. Pay closer attention to new accounts, or 
accounts that are otherwise high-risk.

- Monitor for signs of replay via abuse reports and third party tools
- Oversign Date and Subject headers
- Set signature expiration via x=, with expiration on the order of 30 
minutes to a few days, depending on details of your signing processes

- After implementing oversigning and signature expiration, rotate keys
- Consider signing mail from new or higher risk accounts differently - 
perhaps using a shorter signature expiration or different signing domain


Implied here is that Date and Subject are signed in the first place, 
which in practice is almost always the case. In a small (n=35) survey 
of my own personal mail last year, 97% of sending platforms signed 
Subject, and 89% signed Date.


Top two most effective techniques here, in terms of minimizing 
long-term viability of replay, are 1) signature expiration, and 2) 
shorter expiration for higher-risk accounts.


I have to say that there is a fair amount of irony in my eyes going on 
here. Even though I'm fairly skeptical about what we can actually do 
about this, it's very ironic that x= was my idea (it was in the original 
IIM draft) and that there was a lot of skepticism back then about its 
utility which I had to push back on.


Have you considered something like rate limiting on the receiver side 
for things with duplicate msg-id's? Aka, a tar pit, iirc?


And to be clear, what do you mean by "oversigning"? Is it something 
different than just signing the Subject, etc, header in the first place?


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Alessandro Vesely]

On Tue 14/Feb/2023 06:43:22 +0100 Evan Burke wrote:

On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas  wrote:

On 2/10/23 2:10 PM, Evan Burke wrote:

The M3AAWG BCP will cover recommended header signing/oversigning policies. 
I'll make sure that's shared here when it's published.


Any idea when that might drop?


I'll roughly summarize the guidance here for now. [...]

Top two most effective techniques here, in terms of minimizing long-term
viability of replay, are 1) signature expiration, and 2) shorter expiration
for higher-risk accounts.



Aha, (2) implies different signing based on account.  Are there other 
differences in the signatures, in particular of the type that can be seen by 
receivers (e.g. i=bullshitters@...)?



Best
Ale
--





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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas  wrote:

> On 2/10/23 2:10 PM, Evan Burke wrote:
>
> The M3AAWG BCP will cover recommended header signing/oversigning policies.
> I'll make sure that's shared here when it's published.
>
> Any idea when that might drop?
>

I'll roughly summarize the guidance here for now. The primary audience for
these recommendations is senders/signers with high volume shared signing
domains; these domains are prime targets for replay because of their good
reputation. Other approaches exist, but these are the ones that can
generally be implemented relatively quickly.

- Screen new accounts based on industry standard methods
- Scan outbound mail for spam-like content, and restrict or block sending
based on results. Pay closer attention to new accounts, or accounts that
are otherwise high-risk.
- Monitor for signs of replay via abuse reports and third party tools
- Oversign Date and Subject headers
- Set signature expiration via x=, with expiration on the order of 30
minutes to a few days, depending on details of your signing processes
- After implementing oversigning and signature expiration, rotate keys
- Consider signing mail from new or higher risk accounts differently -
perhaps using a shorter signature expiration or different signing domain

Implied here is that Date and Subject are signed in the first place, which
in practice is almost always the case. In a small (n=35) survey of my own
personal mail last year, 97% of sending platforms signed Subject, and 89%
signed Date.

Top two most effective techniques here, in terms of minimizing long-term
viability of replay, are 1) signature expiration, and 2) shorter expiration
for higher-risk accounts.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Mon, Feb 13, 2023 at 10:42 AM Michael Thomas  wrote:

>
> On 2/13/23 2:49 AM, Laura Atkins wrote:
> >
> > Basically saying if you're not filtering outbound mail for abuse,
> > you're part of the problem.
> >
> > I don’t see how that’s relevant to the discussion here.
> It's extremely relevant. If you don't want to be viewed as a spamming
> domain, do your part to not send spam. This really isn't rocket science.
> >
> > Most of the outbound mail is not detectable as spam (it’s not sent in
> > bulk and it is sent to opt-in email addresses). So it won’t catch the
> > send-one-message-to-myself case. If we’re looking at linking to spam
> > landing sites, it’s trivial for the site to show one thing during the
> > initial send and then be a wholly different site when it’s sent by the
> > spammer.
> According to some others here, the spammers have to go to elaborate ends
> to not have it detected as spam. I don't recall if they specified
> whether it was incoming or outgoing (or both) that they needed to evade.
>

Both - the spam group executing these replay attacks engages in extensive
testing to identify and exploit any weakness in inbound and outbound
filters. DKIM replay using a good-reputation signing domain is one way
through certain inbound filters. Manual testing of different content, to
find what's least suspicious, is a way through both outbound and inbound
filters. (DKIM replay is not their only way through inbound filters, but
it's what we're here to talk about.)

No reasonable large-scale sender operates without outbound filtering, but
given how much time this spam group spends finding content that passes
filtering, and the high amplification factor of replay (1 million to 1 is
not unheard of), outbound filtering is a minimally effective defense
against replay.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/13/23 2:49 AM, Laura Atkins wrote:


Basically saying if you're not filtering outbound mail for abuse, 
you're part of the problem.


I don’t see how that’s relevant to the discussion here.
It's extremely relevant. If you don't want to be viewed as a spamming 
domain, do your part to not send spam. This really isn't rocket science.


Most of the outbound mail is not detectable as spam (it’s not sent in 
bulk and it is sent to opt-in email addresses). So it won’t catch the 
send-one-message-to-myself case. If we’re looking at linking to spam 
landing sites, it’s trivial for the site to show one thing during the 
initial send and then be a wholly different site when it’s sent by the 
spammer.
According to some others here, the spammers have to go to elaborate ends 
to not have it detected as spam. I don't recall if they specified 
whether it was incoming or outgoing (or both) that they needed to evade.


The issue at hand is: can we tighten up the DKIM protocol to make it 
more resistant to replay attacks? Telling the victims that the problem 
is they’re not doing outbound filtering isn’t helpful, nor does it 
address the problem. Expecting the spammer to do outbound filtering 
doesn’t seem to be a useful pathway. If we could convince spammers to 
outbound filter their spam we’d have solved the problem.


Er, huh? It's the sending provider who should be doing outbound 
filtering, not the spammer. And sorry, if you want to keep your 
reputation as a sender up and you're not doing outbound filtering you 
really have nobody to blame but yourself. You're essentially an open relay.


Mike


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Laura Atkins]

> On 12 Feb 2023, at 21:49, Michael Thomas  wrote:
> 
> 
> 
> On 2/12/23 1:34 PM, Murray S. Kucherawy wrote:
>> On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas > > wrote:
>> Another thing that should probably be discussed is outbound spam filtering. 
>> At a high level, this is really about the sender sending spam. But email 
>> afaik is silent on whether senders or receivers should filter for spam (and 
>> if there is, it would be good to reference it). Sender filtering is 
>> especially pertinent and may well have clues of how a sender can mitigate 
>> it. A breakdown of how spammers defeat that outbound filtering would be 
>> really useful. For example, is the spam intended for mailboxes on the 
>> sending domain (eg, gmail)? Or do they go through a two stage process where 
>> they first get the spam through the sender, and then test it on the intended 
>> receiving domains? All of that would be really helpful.
>> 
>> I think it's sufficient for us to acknowledge that, in either direction, no 
>> spam filter is 100% accurate.  It can be tempting to say "You shouldn't sign 
>> spam, and if you do, you're the problem", but I'm sympathetic to those in 
>> that business who are faced with the reality that they'll never get it 100% 
>> right.  Instead, I think we have to accept that reputable signers will 
>> occasionally be tricked into signing spam, and the goal then is to try to 
>> develop some new signal that can be provided to verifiers to handle those 
>> cases. 
>> 
>> The problem statement document proposed for the WG does spell this out, I 
>> think.  What do you find missing in terms of the details?  Some of the nitty 
>> gritty probably varies from one email provider to the next, for example.
>> 
> It didn't exactly call it out? It called out outsourced outbound filtering I 
> thought, but that's just acknowledging that it exists? Or did I miss 
> something? 
> 
> Maybe what's needed is essentially what you wrote. 
> 
> "while senders intent on keeping a good reputation must filter outbound mail 
> for spam and other abuse, these filters are not 100% effective." 
> 
> Basically saying if you're not filtering outbound mail for abuse, you're part 
> of the problem.
> 
I don’t see how that’s relevant to the discussion here. 

Most of the outbound mail is not detectable as spam (it’s not sent in bulk and 
it is sent to opt-in email addresses). So it won’t catch the 
send-one-message-to-myself case. If we’re looking at linking to spam landing 
sites, it’s trivial for the site to show one thing during the initial send and 
then be a wholly different site when it’s sent by the spammer. 

The issue at hand is: can we tighten up the DKIM protocol to make it more 
resistant to replay attacks? Telling the victims that the problem is they’re 
not doing outbound filtering isn’t helpful, nor does it address the problem. 
Expecting the spammer to do outbound filtering doesn’t seem to be a useful 
pathway. If we could convince spammers to outbound filter their spam we’d have 
solved the problem.

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 3:11 PM, Michael Thomas wrote:



On 2/10/23 10:23 AM, Wei Chuang wrote:

| resign for DKIM on behalf of the Originator though the
| Originator increases risk of losing control of their private key.

I'm pretty sure that the best practice here is to just create a 
selector(s) for the ESP's, etc, signing keys. You definitely don't 
want to be handing your private keys out.



And almost as if on cue, Namecheap who should know better didn't.

https://www.namecheap.com/status-updates/archives/74848

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/12/23 12:15 AM, Wei Chuang wrote:

Consolidating the new points raised and my replies:

On Fri, Feb 10, 2023 Michael Thomas  wrote:

Another thing that should probably be discussed is outbound spam
filtering. At a high level, this is really about the sender
sending spam. But email afaik is silent on whether senders or
receivers should filter for spam (and if there is, it would be
good to reference it). Sender filtering is especially pertinent
and may well have clues of how a sender can mitigate it. A
breakdown of how spammers defeat that outbound filtering would be
really useful. For example, is the spam intended for mailboxes on
the sending domain (eg, gmail)? Or do they go through a two stage
process where they first get the spam through the sender, and then
test it on the intended receiving domains? All of that would be
really helpful.

Many MBP have outbound and inbound spam filters.  Many domains also 
use third party Outbound Filtering Services and Inbound Filtering 
Services as mentioned in the Problem Statement draft.
If there is a BCP, I think it's sort of table stakes that outbound 
filtering takes place. That goes for ESP's with marketing email as well. 
I expect that that is just preaching to the choir though.


I understand that Google is not going to tell us exactly how it
makes its filtering and reputation decisions, but that sort of
begs the question of whether we can know what is "best" or
"common" given that we don't know what is "not best" and "not
common" out in the industry. Obviously if we can observe behavior
from the outside (eg, not signing To: and Subject:) that's fair
game. But a nebulous "lowers the reputation" leaves us to just
speculate as to what that means. That is not a very good place to
be in for a standards body.

I think that stake holders are going to have to come to some
consensus of what they will and won't share. That in turn will
inform the wg what it can and can't do. If the problem statement
remains really vague, that means the solution space is going to be
further constrained.

There will alway be this tension between what is proprietary and what 
can be shared so that we collectively work on the problem.  Perhaps 
the way to break the impasse is to say let's move away from reputation 
systems as they are inherently non-deterministic to some deterministic 
solution for DKIM replay.  As an example, a couple of the proposals 
work on signing MAIL FROM recipients and verifying the actual 
recipient against the signed recipients.   The computed will be 
consistent when evaluated at different times unlike reputation systems.


But that breaks indirect mail flows, right? How does a sender know that 
the MX domain isn't the final domain?


Of course if you don't want to support indirect flows, all you need to 
do is put up a SPF record and not DKIM sign it. No need to do any 
unnatural layer violating acts.



Why do you say it weakens it? Isn't it pretty common to import the
SPF record of ESPs, and in this case outbound filters into the
sending domain's SPF record?

If it does weaken it, wouldn't that apply to the ESP case too?

Fair enough.  Yes that applies there too.



But how does it weaken it? Or is that what the Fair Enough is pertaining 
to?


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/12/23 1:34 PM, Murray S. Kucherawy wrote:

On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas  wrote:

Another thing that should probably be discussed is outbound spam
filtering. At a high level, this is really about the sender
sending spam. But email afaik is silent on whether senders or
receivers should filter for spam (and if there is, it would be
good to reference it). Sender filtering is especially pertinent
and may well have clues of how a sender can mitigate it. A
breakdown of how spammers defeat that outbound filtering would be
really useful. For example, is the spam intended for mailboxes on
the sending domain (eg, gmail)? Or do they go through a two stage
process where they first get the spam through the sender, and then
test it on the intended receiving domains? All of that would be
really helpful.


I think it's sufficient for us to acknowledge that, in either 
direction, no spam filter is 100% accurate.  It can be tempting to say 
"You shouldn't sign spam, and if you do, you're the problem", but I'm 
sympathetic to those in that business who are faced with the reality 
that they'll never get it 100% right.  Instead, I think we have to 
accept that reputable signers will occasionally be tricked into 
signing spam, and the goal then is to try to develop some new signal 
that can be provided to verifiers to handle those cases.


The problem statement document proposed for the WG does spell this 
out, I think.  What do you find missing in terms of the details?  Some 
of the nitty gritty probably varies from one email provider to the 
next, for example.


It didn't exactly call it out? It called out outsourced outbound 
filtering I thought, but that's just acknowledging that it exists? Or 
did I miss something?


Maybe what's needed is essentially what you wrote.

"while senders intent on keeping a good reputation must filter outbound 
mail for spam and other abuse, these filters are not 100% effective."


Basically saying if you're not filtering outbound mail for abuse, you're 
part of the problem.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas  wrote:

> Another thing that should probably be discussed is outbound spam
> filtering. At a high level, this is really about the sender sending spam.
> But email afaik is silent on whether senders or receivers should filter for
> spam (and if there is, it would be good to reference it). Sender filtering
> is especially pertinent and may well have clues of how a sender can
> mitigate it. A breakdown of how spammers defeat that outbound filtering
> would be really useful. For example, is the spam intended for mailboxes on
> the sending domain (eg, gmail)? Or do they go through a two stage process
> where they first get the spam through the sender, and then test it on the
> intended receiving domains? All of that would be really helpful.
>

I think it's sufficient for us to acknowledge that, in either direction, no
spam filter is 100% accurate.  It can be tempting to say "You shouldn't
sign spam, and if you do, you're the problem", but I'm sympathetic to those
in that business who are faced with the reality that they'll never get it
100% right.  Instead, I think we have to accept that reputable signers will
occasionally be tricked into signing spam, and the goal then is to try to
develop some new signal that can be provided to verifiers to handle those
cases.

The problem statement document proposed for the WG does spell this out, I
think.  What do you find missing in terms of the details?  Some of the
nitty gritty probably varies from one email provider to the next, for
example.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Wei Chuang]

Consolidating the new points raised and my replies:

On Fri, Feb 10, 2023 Michael Thomas  wrote:

Another thing that should probably be discussed is outbound spam filtering.
At a high level, this is really about the sender sending spam. But email
afaik is silent on whether senders or receivers should filter for spam (and
if there is, it would be good to reference it). Sender filtering is
especially pertinent and may well have clues of how a sender can mitigate
it. A breakdown of how spammers defeat that outbound filtering would be
really useful. For example, is the spam intended for mailboxes on the
sending domain (eg, gmail)? Or do they go through a two stage process where
they first get the spam through the sender, and then test it on the
intended receiving domains? All of that would be really helpful.

Many MBP have outbound and inbound spam filters.  Many domains also use
third party Outbound Filtering Services and Inbound Filtering Services as
mentioned in the Problem Statement draft.

I understand that Google is not going to tell us exactly how it makes its
filtering and reputation decisions, but that sort of begs the question of
whether we can know what is "best" or "common" given that we don't know
what is "not best" and "not common" out in the industry. Obviously if we
can observe behavior from the outside (eg, not signing To: and Subject:)
that's fair game. But a nebulous "lowers the reputation" leaves us to just
speculate as to what that means. That is not a very good place to be in for
a standards body.

I think that stake holders are going to have to come to some consensus of
what they will and won't share. That in turn will inform the wg what it can
and can't do. If the problem statement remains really vague, that means the
solution space is going to be further constrained.

There will alway be this tension between what is proprietary and what can
be shared so that we collectively work on the problem.  Perhaps the way to
break the impasse is to say let's move away from reputation systems as they
are inherently non-deterministic to some deterministic solution for DKIM
replay.  As an example, a couple of the proposals work on signing MAIL FROM
recipients and verifying the actual recipient against the signed
recipients.   The computed will be consistent when evaluated at different
times unlike reputation systems.

Why do you say it weakens it? Isn't it pretty common to import the SPF
record of ESPs, and in this case outbound filters into the sending domain's
SPF record?

If it does weaken it, wouldn't that apply to the ESP case too?

Fair enough.  Yes that applies there too.

The other two points are observations which I think I largely agree with.

-Wei



On Sat, Feb 11, 2023 at 2:40 PM Michael Thomas  wrote:

>
> On 2/10/23 9:36 PM, Murray S. Kucherawy wrote:
>
> On Fri, Feb 10, 2023 at 12:06 PM Evan Burke  40mailchimp@dmarc.ietf.org> wrote:
>
>>
>> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker  wrote:
>>
>>> On 2/10/2023 11:35 AM, Wei Chuang wrote:
>>> > ARC is a tool to help support modern Indirect Mail Flows, and I
>>> > believe belongs in the solution space to be explored.
>>>
>>> Since ARC uses the same technology as DKIM and uses it in pretty much
>>> the same was, my understanding is that it, too, has the potential for
>>> replay.  Having a reference to this fact makes sense to me.
>>>
>>> It doesn't need more than a mention, at this point, I believe, which
>>> makes the current quick, reference exactly the right text, IMO.
>>>
>>
>> +1
>>
>> I realize there are some mixed opinions on ARC, but it's actively used on
>> several of the world's largest email systems - some of the same ones where
>> DKIM replay attacks are focused - so it's worth consideration as part of
>> the solution space. It may not end up being a viable option, but now isn't
>> the time to write it off.
>>
>
> Speaking only as a participant:
>
> I also don't think a comment like "ARC has the same problem, for largely
> the same reasons" is by itself harmful here.
>
> What I think we should be sure to avoid is expending WG energy trying to
> solve this problem in ARC-space.  That, I would argue, is outside the
> charter.
>
> I see that they took out a lot of other mentions in this rev, but I have a
> real problem with editorializing that ARC does this or ARC does that which
> is to say the least, controversial. It's really not germane to this wg and
> imo the easiest thing to do is nothing at all wrt ARC.
>
> Mike
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 9:36 PM, Murray S. Kucherawy wrote:
On Fri, Feb 10, 2023 at 12:06 PM Evan Burke 
 wrote:



On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker 
wrote:

On 2/10/2023 11:35 AM, Wei Chuang wrote:
> ARC is a tool to help support modern Indirect Mail Flows, and I
> believe belongs in the solution space to be explored.

Since ARC uses the same technology as DKIM and uses it in
pretty much
the same was, my understanding is that it, too, has the
potential for
replay.  Having a reference to this fact makes sense to me.

It doesn't need more than a mention, at this point, I believe,
which
makes the current quick, reference exactly the right text, IMO.


+1

I realize there are some mixed opinions on ARC, but it's actively
used on several of the world's largest email systems - some of the
same ones where DKIM replay attacks are focused - so it's worth
consideration as part of the solution space. It may not end up
being a viable option, but now isn't the time to write it off.


Speaking only as a participant:

I also don't think a comment like "ARC has the same problem, for 
largely the same reasons" is by itself harmful here.


What I think we should be sure to avoid is expending WG energy trying 
to solve this problem in ARC-space.  That, I would argue, is outside 
the charter.


I see that they took out a lot of other mentions in this rev, but I have 
a real problem with editorializing that ARC does this or ARC does that 
which is to say the least, controversial. It's really not germane to 
this wg and imo the easiest thing to do is nothing at all wrt ARC.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Murray S. Kucherawy]

On Fri, Feb 10, 2023 at 12:06 PM Evan Burke  wrote:

>
> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker  wrote:
>
>> On 2/10/2023 11:35 AM, Wei Chuang wrote:
>> > ARC is a tool to help support modern Indirect Mail Flows, and I
>> > believe belongs in the solution space to be explored.
>>
>> Since ARC uses the same technology as DKIM and uses it in pretty much
>> the same was, my understanding is that it, too, has the potential for
>> replay.  Having a reference to this fact makes sense to me.
>>
>> It doesn't need more than a mention, at this point, I believe, which
>> makes the current quick, reference exactly the right text, IMO.
>>
>
> +1
>
> I realize there are some mixed opinions on ARC, but it's actively used on
> several of the world's largest email systems - some of the same ones where
> DKIM replay attacks are focused - so it's worth consideration as part of
> the solution space. It may not end up being a viable option, but now isn't
> the time to write it off.
>

Speaking only as a participant:

I also don't think a comment like "ARC has the same problem, for largely
the same reasons" is by itself harmful here.

What I think we should be sure to avoid is expending WG energy trying to
solve this problem in ARC-space.  That, I would argue, is outside the
charter.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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


| Transmission through an Inbound Filtering Service

I think it should be made clear that SPF will fail if checked on any 
receiver farther downstream from the MX record. I think that's really 
what's going on here, and has little to do with filtering services, etc.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

| resign for DKIM on behalf of the Originator though the
| Originator increases risk of losing control of their private key.

I'm pretty sure that the best practice here is to just create a 
selector(s) for the ESP's, etc, signing keys. You definitely don't want 
to be handing your private keys out.


That's how gmail hosts and signs for my domain here.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:



[]


SPF authentication is possible, but may not be advisable.  The
Originator does this by publishing an SPF policy that covers the
Outbound Filtering Service IPs but this IP sharing weakens
authentication.

Why do you say it weakens it? Isn't it pretty common to import the SPF 
record of ESPs, and in this case outbound filters into the sending 
domain's SPF record?


If it does weaken it, wouldn't that apply to the ESP case too?

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 2:10 PM, Evan Burke wrote:



On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas  wrote:


| taking advantage of the flexibility in DKIM to
| selectively sign headers, the spammer may intentionally leave out
| certain headers such as To:, and Subject: that can be added in later
| without damaging the existing DKIM signature.

I think this needs to be explained. It isn't obvious to me
how they would manage to do that. The header fields signed
are under control of the signer, not the original author. How
do the attackers coax the provider's signer into not signing
certain fields?

By leaving them out.  Many DKIM signers, having observed this
vulnerability, have started oversigning headers to prevent that.


I think the draft should flesh this out a bit more. I mean, are
they just doing a bcc without a To: address? Are there other
mechanisms? Is that suspicious or is it a legit behavior? I don't
think I've seen a message without a To: address (or at least a
legit one).


I more frequently saw replay attackers adding a second set of certain 
headers to the message during replay. As long as the original header 
was still present and matched the signature hash, the signature was 
intact. Regardless, oversigning solves both cases.


Then it should be in the problem statement of what they are doing. A 
well documented account of the current cat and mouse game would be 
really helpful. Speculation on where it it may go would be helpful too. 
I'm sure that text would be appreciated too. (if it isn't obvious, this 
draft seems like a good way forward on the problem statement to me).




(again, this will be important to inform possible BCP things, and
in the case of To: and Subject: to possibly making them required
to be signed in a protocol change. certainly that might be an
interesting discussion)

The M3AAWG BCP will cover recommended header signing/oversigning 
policies. I'll make sure that's shared here when it's published.



Any idea when that might drop?

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 2:11 PM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 1:48 PM Michael Thomas  wrote:

| When large amounts of spam are received by the mailbox provider,
the

| operator’s filtering engine will eventually react by dropping the
| reputation of the original DKIM signer.

I think this needs some amount of justification. It's really easy
to hand wave this and it's certainly a common assumption, but it's
not a given. What exactly does "dropping the reputation" actually
mean in practice? Does it mean for certain senders, certain
classes of senders, the whole sending domain? How are such drops
weighted? What are plausible metrics the receiver might use? One
mailbox sending a lot of spam but otherwise the sending domain
seems to be behaving well, seems pretty relevant to the topic.

This is especially true if a BCP gets written here. The problem
statement should be as specific as it can be about why it's hard
for receivers to overcome this problem. If there's a lot of
proprietary stuff that can't be talked about, then it's pretty
impossible to put together a BCP since we collectively have no
idea what those practices are.

I think this really goes to the heart of what's going on here.

Mike

Agreed there is a certain amount of hand waviness and things have to 
be described abstractly as various black boxes in the system due to 
their proprietary nature.  But I think it is necessary to mention them 
to motivate the deliverability aspect of the problem i.e. why it is 
impacted, to provide some intuition for the problem space. 
Similarly how DKIM replay impacts the utility of email to the end 
users.  I think we would agree that there is a preference for a 
deterministic DKIM replay solution and avoid reputation systems where 
possible.


I understand that Google is not going to tell us exactly how it makes 
its filtering and reputation decisions, but that sort of begs the 
question of whether we can know what is "best" or "common" given that we 
don't know what is "not best" and "not common" out in the industry. 
Obviously if we can observe behavior from the outside (eg, not signing 
To: and Subject:) that's fair game. But a nebulous "lowers the 
reputation" leaves us to just speculate as to what that means. That is 
not a very good place to be in for a standards body.


I think that stake holders are going to have to come to some consensus 
of what they will and won't share. That in turn will inform the wg what 
it can and can't do. If the problem statement remains really vague, that 
means the solution space is going to be further constrained.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


Another thing that should probably be discussed is outbound spam 
filtering. At a high level, this is really about the sender sending 
spam. But email afaik is silent on whether senders or receivers should 
filter for spam (and if there is, it would be good to reference it). 
Sender filtering is especially pertinent and may well have clues of how 
a sender can mitigate it. A breakdown of how spammers defeat that 
outbound filtering would be really useful. For example, is the spam 
intended for mailboxes on the sending domain (eg, gmail)? Or do they go 
through a two stage process where they first get the spam through the 
sender, and then test it on the intended receiving domains? All of that 
would be really helpful.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

On 2/10/2023 1:47 PM, Wei Chuang wrote:


| In addition to being DKIM authenticated via the spoofed DKIM signature


...
To be honest I was wondering about that word choice myself. I can 
change that in the next rev.



There is a long-standing misuse of the term spoof, in the anti-abuse 
community.  This is in spite of constant efforts to correct the 
(mis)practice.


So, when someone authorized to use an address, then its use is not spoofing.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Wei Chuang]

On Fri, Feb 10, 2023 at 1:48 PM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
> -Wei
>
> PS Many, many thanks goes to Dave Crocker for his editorial advice.
>
> ___
> Ietf-dkim mailing 
> listIetf-dkim@ietf.orghttps://www.ietf.org/mailman/listinfo/ietf-dkim
>
>
> | When large amounts of spam are received by the mailbox provider, the
> | operator’s filtering engine will eventually react by dropping the
> | reputation of the original DKIM signer.
>
>
> I think this needs some amount of justification. It's really easy to hand
> wave this and it's certainly a common assumption, but it's not a given.
> What exactly does "dropping the reputation" actually mean in practice? Does
> it mean for certain senders, certain classes of senders, the whole sending
> domain? How are such drops weighted? What are plausible metrics the
> receiver might use? One mailbox sending a lot of spam but otherwise the
> sending domain seems to be behaving well, seems pretty relevant to the
> topic.
>
> This is especially true if a BCP gets written here. The problem statement
> should be as specific as it can be about why it's hard for receivers to
> overcome this problem. If there's a lot of proprietary stuff that can't be
> talked about, then it's pretty impossible to put together a BCP since we
> collectively have no idea what those practices are.
>
> I think this really goes to the heart of what's going on here.
>
> Mike
>
> Agreed there is a certain amount of hand waviness and things have to be
described abstractly as various black boxes in the system due to their
proprietary nature.  But I think it is necessary to mention them to
motivate the deliverability aspect of the problem i.e. why it is impacted,
to provide some intuition for the problem space.  Similarly how DKIM replay
impacts the utility of email to the end users.  I think we would agree that
there is a preference for a deterministic DKIM replay solution and avoid
reputation systems where possible.

-Wei


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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas  wrote:

> | taking advantage of the flexibility in DKIM to
>> | selectively sign headers, the spammer may intentionally leave out
>> | certain headers such as To:, and Subject: that can be added in later
>> | without damaging the existing DKIM signature.
>>
>>
>> I think this needs to be explained. It isn't obvious to me how they would
>> manage to do that. The header fields signed are under control of the
>> signer, not the original author. How do the attackers coax the provider's
>> signer into not signing certain fields?
>>
> By leaving them out.  Many DKIM signers, having observed this
> vulnerability, have started oversigning headers to prevent that.
>
> I think the draft should flesh this out a bit more. I mean, are they just
> doing a bcc without a To: address? Are there other mechanisms? Is that
> suspicious or is it a legit behavior? I don't think I've seen a message
> without a To: address (or at least a legit one).
>

I more frequently saw replay attackers adding a second set of certain
headers to the message during replay. As long as the original header was
still present and matched the signature hash, the signature was intact.
Regardless, oversigning solves both cases.

(again, this will be important to inform possible BCP things, and in the
> case of To: and Subject: to possibly making them required to be signed in a
> protocol change. certainly that might be an interesting discussion)
>

The M3AAWG BCP will cover recommended header signing/oversigning policies.
I'll make sure that's shared here when it's published.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 1:48 PM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 1:29 PM Michael Thomas  wrote:


On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the
draft-chuang-dkim-replay-problem-01

draft.  It cleans up a lot from the -00 rough draft state so
hopefully it's more clear.  It builds a case that spammers are
exploiting DKIM through replay, identifies conflicting scenarios,
and outlines a solution space.



| taking advantage of the flexibility in DKIM to
| selectively sign headers, the spammer may intentionally leave out
| certain headers such as To:, and Subject: that can be added in later
| without damaging the existing DKIM signature.

I think this needs to be explained. It isn't obvious to me how
they would manage to do that. The header fields signed are under
control of the signer, not the original author. How do the
attackers coax the provider's signer into not signing certain fields?

By leaving them out.  Many DKIM signers, having observed this 
vulnerability, have started oversigning headers to prevent that.


I think the draft should flesh this out a bit more. I mean, are they 
just doing a bcc without a To: address? Are there other mechanisms? Is 
that suspicious or is it a legit behavior? I don't think I've seen a 
message without a To: address (or at least a legit one).


(again, this will be important to inform possible BCP things, and in the 
case of To: and Subject: to possibly making them required to be signed 
in a protocol change. certainly that might be an interesting discussion)


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 1:47 PM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 1:33 PM Michael Thomas  wrote:


On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the
draft-chuang-dkim-replay-problem-01

draft.  It cleans up a lot from the -00 rough draft state so
hopefully it's more clear.  It builds a case that spammers are
exploiting DKIM through replay, identifies conflicting scenarios,
and outlines a solution space.

-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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



| In addition to being DKIM authenticated via the spoofed DKIM signature

I'm pretty sure that spoofed is wrong here? It's the originating
domain's signature signed by their signers, still right? That's
not spoofing.

To be honest I was wondering about that word choice myself.  I can 
change that in the next rev.



Ok, thanks. It had me really confused.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Wei Chuang]

On Fri, Feb 10, 2023 at 1:29 PM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
>
> | taking advantage of the flexibility in DKIM to
> | selectively sign headers, the spammer may intentionally leave out
> | certain headers such as To:, and Subject: that can be added in later
> | without damaging the existing DKIM signature.
>
>
> I think this needs to be explained. It isn't obvious to me how they would
> manage to do that. The header fields signed are under control of the
> signer, not the original author. How do the attackers coax the provider's
> signer into not signing certain fields?
>
By leaving them out.  Many DKIM signers, having observed this
vulnerability, have started oversigning headers to prevent that.

 -Wei

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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



| When large amounts of spam are received by the mailbox provider, the
| operator’s filtering engine will eventually react by dropping the
| reputation of the original DKIM signer.

I think this needs some amount of justification. It's really easy to 
hand wave this and it's certainly a common assumption, but it's not a 
given. What exactly does "dropping the reputation" actually mean in 
practice? Does it mean for certain senders, certain classes of senders, 
the whole sending domain? How are such drops weighted? What are 
plausible metrics the receiver might use? One mailbox sending a lot of 
spam but otherwise the sending domain seems to be behaving well, seems 
pretty relevant to the topic.


This is especially true if a BCP gets written here. The problem 
statement should be as specific as it can be about why it's hard for 
receivers to overcome this problem. If there's a lot of proprietary 
stuff that can't be talked about, then it's pretty impossible to put 
together a BCP since we collectively have no idea what those practices are.


I think this really goes to the heart of what's going on here.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Wei Chuang]

On Fri, Feb 10, 2023 at 1:33 PM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
> -Wei
>
> PS Many, many thanks goes to Dave Crocker for his editorial advice.
>
> ___
> Ietf-dkim mailing 
> listIetf-dkim@ietf.orghttps://www.ietf.org/mailman/listinfo/ietf-dkim
>
>
> | In addition to being DKIM authenticated via the spoofed DKIM signature
>
>
> I'm pretty sure that spoofed is wrong here? It's the originating domain's
> signature signed by their signers, still right? That's not spoofing.
>
To be honest I was wondering about that word choice myself.  I can change
that in the next rev.

-Wei


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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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



| In addition to being DKIM authenticated via the spoofed DKIM signature

I'm pretty sure that spoofed is wrong here? It's the originating 
domain's signature signed by their signers, still right? That's not 
spoofing.


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.




| taking advantage of the flexibility in DKIM to
| selectively sign headers, the spammer may intentionally leave out
| certain headers such as To:, and Subject: that can be added in later
| without damaging the existing DKIM signature.

I think this needs to be explained. It isn't obvious to me how they 
would manage to do that. The header fields signed are under control of 
the signer, not the original author. How do the attackers coax the 
provider's signer into not signing certain fields?


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

On 2/10/2023 12:05 PM, Evan Burke wrote:
I realize there are some mixed opinions on ARC, but it's actively used 
on several of the world's largest email systems -


The problem document is not an exercise in politics but an exploration 
of technical and operational issues.


Whether one or another technology is wonderful or the devil's work 
should be entirely out of scope, IMO.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker  wrote:

> On 2/10/2023 11:35 AM, Wei Chuang wrote:
> > ARC is a tool to help support modern Indirect Mail Flows, and I
> > believe belongs in the solution space to be explored.
>
> Since ARC uses the same technology as DKIM and uses it in pretty much
> the same was, my understanding is that it, too, has the potential for
> replay.  Having a reference to this fact makes sense to me.
>
> It doesn't need more than a mention, at this point, I believe, which
> makes the current quick, reference exactly the right text, IMO.
>

+1

I realize there are some mixed opinions on ARC, but it's actively used on
several of the world's largest email systems - some of the same ones where
DKIM replay attacks are focused - so it's worth consideration as part of
the solution space. It may not end up being a viable option, but now isn't
the time to write it off.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Dave Crocker]

On 2/10/2023 11:35 AM, Wei Chuang wrote:
ARC is a tool to help support modern Indirect Mail Flows, and I 
believe belongs in the solution space to be explored. 


Since ARC uses the same technology as DKIM and uses it in pretty much 
the same was, my understanding is that it, too, has the potential for 
replay.  Having a reference to this fact makes sense to me.


It doesn't need more than a mention, at this point, I believe, which 
makes the current quick, reference exactly the right text, IMO.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 11:35 AM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas  wrote:


On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the
draft-chuang-dkim-replay-problem-01

draft.  It cleans up a lot from the -00 rough draft state so
hopefully it's more clear.  It builds a case that spammers are
exploiting DKIM through replay, identifies conflicting scenarios,
and outlines a solution space.



Again, drop the reference to ARC. it is: 1) Experimental, 2) the
claim about it is wrong (DKIM can already sign a previous
auth-res), and 3) this is the DKIM wg and it holds no power to
make changes in it anyway.

I disagree.  ARC is a tool to help support modern Indirect Mail 
Flows, and I believe belongs in the solution space to be explored.  
The large section in that draft is explicitly to make the point that 
we need to support those Indirect Mail Flows when we come up with a 
solution for DKIM Replay.  Please come up with a workable proposal 
preferably in I-D form to support Indirect Mail Flows and prevent DKIM 
replay.


I will do no such thing. I've already made it plain here and elsewhere 
that I don't think there is a solution to the mailing list problem, and 
trust me there is probably nobody else who has tried more. That's why I 
wrote this:


https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html

And regardless of whether I'm wrong and there is a ultimate solution, 
ARC most certainly is not that solution. It's not doing anything that 
DKIM can't already do and the "seal" mechanism is extremely suspect as 
to what it's actually providing. Thank goodness it was just an experiment.


But as I said, this is the DKIM working group. If DMARC wants to update 
ARC after this iteration of this wg concludes, they are more than 
entitled take that work up.


Mike, would that I had known about ARC before it hit the streets.

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Wei Chuang]

On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
>
> Again, drop the reference to ARC. it is: 1) Experimental, 2) the claim
> about it is wrong (DKIM can already sign a previous auth-res), and 3) this
> is the DKIM wg and it holds no power to make changes in it anyway.
>
I disagree.  ARC is a tool to help support modern Indirect Mail Flows, and
I believe belongs in the solution space to be explored.  The large section
in that draft is explicitly to make the point that we need to support those
Indirect Mail Flows when we come up with a solution for DKIM Replay.
Please come up with a workable proposal preferably in I-D form to support
Indirect Mail Flows and prevent DKIM replay.

-Wei

> When we finally get some chairs, we should make it explicitly out of scope.
>
> Mike
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.




Again, drop the reference to ARC. it is: 1) Experimental, 2) the claim 
about it is wrong (DKIM can already sign a previous auth-res), and 3) 
this is the DKIM wg and it holds no power to make changes in it anyway.


When we finally get some chairs, we should make it explicitly out of scope.

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