Re: [Ietf-dkim] DKIM replay mitigations

[Wei Chuang]

I've fixed up the RFC references in 01 draft of
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/

As to the DKIM replay definition question, Murray noted that the DKIM RFC
(RFC6376) already says something about DKIM replay as when they were
writing it, they had suspected it could be a problem.  It's only recently
that it has become a real problem.
-Wei

On Tue, Oct 4, 2022 at 9:16 AM Alessandro Vesely  wrote:

> On Tue 04/Oct/2022 02:01:12 +0200 Scott Kitterman wrote:
> >
> > Many normal email operations seem difficult to distinguish from the case
> you are trying to address.  Signing fields in the envelope may be enough to
> break replaying, although it would have other negative consequences.
>
>
> Scott is right.  In general the envelope can contain jack@site-A and
> jill@site-B.  When the server connects to site-A, it only transmits
> jack.  Jill
> would be rejected with something like "Relaying denied".  So at site-A, a
> signature including the envelope is already broken.
>
> About formatting, don't stuff like:
>
>  ARC (RFC8617 (https://www.rfc-editor.org/rfc/rfc8617.html))
>
> If using XML[*], write references like:
>
>  ARC ()
>
> Or, if using mmark[†]:
>
> ARC ([@!RFC8617])
>
>
> Best
> Ale
> --
>
> [*] https://authors.ietf.org/references-in-rfcxml
> [†] https://mmark.miek.nl/
>
>
>
>
>
>
>
> ___
> 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 mitigations

[Alessandro Vesely]

On Tue 04/Oct/2022 02:01:12 +0200 Scott Kitterman wrote:


Many normal email operations seem difficult to distinguish from the case you 
are trying to address.  Signing fields in the envelope may be enough to break 
replaying, although it would have other negative consequences.



Scott is right.  In general the envelope can contain jack@site-A and 
jill@site-B.  When the server connects to site-A, it only transmits jack.  Jill 
would be rejected with something like "Relaying denied".  So at site-A, a 
signature including the envelope is already broken.


About formatting, don't stuff like:

ARC (RFC8617 (https://www.rfc-editor.org/rfc/rfc8617.html))

If using XML[*], write references like:

ARC ()

Or, if using mmark[†]:

   ARC ([@!RFC8617])


Best
Ale
--

[*] https://authors.ietf.org/references-in-rfcxml
[†] https://mmark.miek.nl/







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

Re: [Ietf-dkim] DKIM replay mitigations

[Scott Kitterman]

At least as I read it, I don't think you are describing the same issue as RFC 
8376, Section 8.6.  It describes the concern as "banking on the reputation of 
the signing domain (e.g., a large popular mailbox provider) rather than its 
own".  I believe that's meant to describe an unaligned (in a DMARC sense) 
message, which seems different than what you are describing.

Many normal email operations seem difficult to distinguish from the case you 
are trying to address.  Signing fields in the envelope may be enough to break 
replaying, although it would have other negative consequences.

Scott K

On October 3, 2022 11:40:55 PM UTC, Wei Chuang 
 wrote:
>I've uploaded a draft describing for a specification that tackles the
>concepts listed below:
>
>https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
>
>Feedback welcome.  (Apologies for the formatting in advance as its a first
>draft)
>-Wei
>
>On Mon, Aug 22, 2022 at 2:53 PM Wei Chuang  wrote:
>
>> Hi,
>> One of the known security challenges in DKIM is its vulnerability to
>> replay attacks as already mentioned in Security Considerations section 8.6
>> ,
>> and has been raised at recent M3AAWGs as a significant challenge.  I'd like
>> to propose a couple of concepts for dealing with DKIM replay.  Depending on
>> where the conversation goes, I can get into proposals for technical
>> specification level proposals.
>>
>> DKIM replay typically takes advantage of capturing a DKIM signed message
>> from the inbox and then rebroadcasting it out to many users.  Taking that
>> observation there are a couple of directions for mitigations.
>> 1. We can try to detect and prevent the recipient amplification.  One way
>> may be to specify that the sender must always DKIM sign for the who the
>> intended recipient is including through mailing lists and forwarding
>> scenarios, in such a way that the receiver can check for this.  If the
>> intended recipient verification fails, then it may be an indication of
>> replay.  This must work for multiple forwarding hops and enterprise
>> scenarios, and when forwarders don't participate.
>> 2. Distinguish signed messages in the inbox versus those in transit.  If
>> we see messages that were signed messages meant to be in the inbox,
>> suddenly in transit again, this likely indicates a replayed message.
>> 3. Strengthen message digital signing to be replay resistant.  Currently
>> DKIM signature's identity just says it is associated with a particular
>> sender.  Perhaps we ought to tie the signature back to a particular SMTP
>> transaction by signing for both the sender, receiver and timestamp.  We
>> could add more specification around the timestamp to make it more workable
>> in the email distributed forwarding system for replay detection.  Put this
>> signature in a framework such as ARC that describes forwarding hops
>> better, so that receivers can make use of those identities with
>> forwarding.  Using ARC as the signing framework also helps proposal 1).
>> Again consider when receivers don't participate.  (This is a highly complex
>> scenario and likely I'm missing important details in trying to summarize)
>>
>> All the while, using ARC as a framework may allow future support for
>> another long standing issue, which is working on message modification while
>> forwarding, in particular for mailing lists.  The proposal
>> draft-kucherawy-dkim-list-canon-01
>>  
>> provides
>> a framework for handling common mailing list modifications by identifying
>> those modifications.  Putting it into ARC, may generalize this by
>> identifying who made the modifications and be able to tolerate multiple
>> such modifications such multiple mailing list expansions.
>>
>> Looking forward to your initial thoughts about feasibility and interest.
>> -Wei
>>

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

Re: [Ietf-dkim] DKIM replay mitigations

[Wei Chuang]

I've uploaded a draft describing for a specification that tackles the
concepts listed below:

https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/

Feedback welcome.  (Apologies for the formatting in advance as its a first
draft)
-Wei

On Mon, Aug 22, 2022 at 2:53 PM Wei Chuang  wrote:

> Hi,
> One of the known security challenges in DKIM is its vulnerability to
> replay attacks as already mentioned in Security Considerations section 8.6
> ,
> and has been raised at recent M3AAWGs as a significant challenge.  I'd like
> to propose a couple of concepts for dealing with DKIM replay.  Depending on
> where the conversation goes, I can get into proposals for technical
> specification level proposals.
>
> DKIM replay typically takes advantage of capturing a DKIM signed message
> from the inbox and then rebroadcasting it out to many users.  Taking that
> observation there are a couple of directions for mitigations.
> 1. We can try to detect and prevent the recipient amplification.  One way
> may be to specify that the sender must always DKIM sign for the who the
> intended recipient is including through mailing lists and forwarding
> scenarios, in such a way that the receiver can check for this.  If the
> intended recipient verification fails, then it may be an indication of
> replay.  This must work for multiple forwarding hops and enterprise
> scenarios, and when forwarders don't participate.
> 2. Distinguish signed messages in the inbox versus those in transit.  If
> we see messages that were signed messages meant to be in the inbox,
> suddenly in transit again, this likely indicates a replayed message.
> 3. Strengthen message digital signing to be replay resistant.  Currently
> DKIM signature's identity just says it is associated with a particular
> sender.  Perhaps we ought to tie the signature back to a particular SMTP
> transaction by signing for both the sender, receiver and timestamp.  We
> could add more specification around the timestamp to make it more workable
> in the email distributed forwarding system for replay detection.  Put this
> signature in a framework such as ARC that describes forwarding hops
> better, so that receivers can make use of those identities with
> forwarding.  Using ARC as the signing framework also helps proposal 1).
> Again consider when receivers don't participate.  (This is a highly complex
> scenario and likely I'm missing important details in trying to summarize)
>
> All the while, using ARC as a framework may allow future support for
> another long standing issue, which is working on message modification while
> forwarding, in particular for mailing lists.  The proposal
> draft-kucherawy-dkim-list-canon-01
>  
> provides
> a framework for handling common mailing list modifications by identifying
> those modifications.  Putting it into ARC, may generalize this by
> identifying who made the modifications and be able to tolerate multiple
> such modifications such multiple mailing list expansions.
>
> Looking forward to your initial thoughts about feasibility and interest.
> -Wei
>


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 mitigations

[Alessandro Vesely]

On Thu 25/Aug/2022 01:36:21 +0200 Wei Chuang wrote:


On Tue, Aug 23, 2022 at 11:07 AM Alessandro Vesely  wrote:

On Mon 22/Aug/2022 23:53:16 +0200 Wei Chuang wrote:
All the while, using ARC as a framework may allow future support 
for another long standing issue, which is working on message 
modification while forwarding, in particular for mailing lists.  The 
proposal draft-kucherawy-dkim-list-canon-01  a framework for 
handling common mailing list modifications by identifying those 
modifications.  Putting it into ARC, may generalize this by 
identifying who made the modifications and be able to tolerate 
multiple such modifications such multiple mailing list expansions. >>

There doesn't seem to be interest in deeply reworking DKIM.


Two of the approaches (first and second) would likely just involve tweaking 
ARC, so the real cost is adopting ARC IMO.  The third proposal is a step up 
in implementation cost, as it likely involves extending SMTP.



Either you allow forwarding or require a strict SPF match.  In the former 
case, you also allow replaying.  There is no way to distinguish the 
original from the copy, unless they're forced to come from or arrive to a 
fixed host.




Regarding better supporting mailing lists:

Another draft, draft-kucherawy-dkim-transform[*] proposed standard 
modifications.  I implemented (a variation of) it and it works about 
50% of cases.  It fails when the original signature covers too many 
fields; for example, if one signs a MIME-Version field with a 
different capitalization, the mailing list will overwrite it and break 
the original signature for good.  Also, altering the order of To: or 
Cc: mailboxes breaks signatures irrecoverably, unless saving 
Original-To:, Original-Cc:, and any other signed field. >
I wonder if some of that could be handled by stronger specification?  It 
would be lighter weight though less interoperable.  In practice did you see 
lots of re-ordering on legitimate traffic?  How much of the 50% benefit was 
found due to better supporting the features in the draft?  1) subject 2) 
footer 3) mime transformations 4) new mime-part?



It becomes a bit tricky in some cases, but for "classic" mailing list 
(Mailman and similar tools) it works fine.  I describe it in a draft:

https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/

There is no interest about it either.



Do you know if anyone tried implementing draft-kucherawy-dkim-list-canon-01?  
And what were the results?



Nope.



There are mailing lists that use ARC, but they also change From:.  ARC was
thought for that case, but it is actually useful in different cases.


Agreed ARC doesn't fully solve support From modification that some mailing
lists do, and needs something like the above draft-kucherawy-dkim-transform
draft.



ARC is used by big players to ascribe reputation correctly.  It doesn't 
work fr mailing lists because changing From: puts determination of the 
original author in jeopardy.  It would be enough to add an Author: field to 
fix the latter.




Also, cannot use ARC to fix the path through mailing list and forwarding
scenarios.  That was attempted by draft-levine-dkim-conditional[†].



Also agree this approach of describing the sending path by the sender can
help with replay scenarios.



It still suffers the same limitation, unless you impose to receive the 
message directly from the 2nd signer.



Best
Ale
--






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

Re: [Ietf-dkim] DKIM replay mitigations

[Wei Chuang]

On Tue, Aug 23, 2022 at 11:07 AM Alessandro Vesely  wrote:

> On Mon 22/Aug/2022 23:53:16 +0200 Wei Chuang wrote:
> > All the while, using ARC as a framework may allow future support for
> > another long standing issue, which is working on message modification
> while
> > forwarding, in particular for mailing lists.  The proposal
> > draft-kucherawy-dkim-list-canon-01
> > <
> https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon-01> 
> provides
>
> > a framework for handling common mailing list modifications by
> identifying
> > those modifications.  Putting it into ARC, may generalize this by
> > identifying who made the modifications and be able to tolerate multiple
> > such modifications such multiple mailing list expansions.
>
>
> There doesn't seem to be interest in deeply reworking DKIM.
>

Two of the approaches (first and second) would likely just involve tweaking
ARC, so the real cost is adopting ARC IMO.  The third proposal is a step up
in implementation cost, as it likely involves extending SMTP.

Regarding better supporting mailing lists:

Another draft, draft-kucherawy-dkim-transform[*] proposed standard
> modifications.  I implemented (a variation of) it and it works about 50%
> of
> cases.  It fails when the original signature covers too many fields; for
> example, if one signs a MIME-Version field with a different
> capitalization,
> the mailing list will overwrite it and break the original signature for
> good.  Also, altering the order of To: or Cc: mailboxes breaks signatures
> irrecoverably, unless saving Original-To:, Original-Cc:, and any other
> signed field.
>

I wonder if some of that could be handled by stronger specification?  It
would be lighter weight though less interoperable.  In practice did you see
lots of re-ordering on legitimate traffic?  How much of the 50% benefit was
found due to better supporting the features in the draft?  1) subject 2)
footer 3) mime transformations 4) new mime-part?

Do you know if anyone tried
implementing draft-kucherawy-dkim-list-canon-01?  And what were the results?


> There are mailing lists that use ARC, but they also change From:.  ARC was
> thought for that case, but it is actually useful in different cases.
>

Agreed ARC doesn't fully solve support From modification that some mailing
lists do, and needs something like the above draft-kucherawy-dkim-transform
draft.


> Also, cannot use ARC to fix the path through mailing list and forwarding
> scenarios.  That was attempted by draft-levine-dkim-conditional[†].
>

Also agree this approach of describing the sending path by the sender can
help with replay scenarios.

-Wei


>
> Best
> Ale
> --
>
>
> [*] https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/
> [†] https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
>
> ___
> 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 mitigations

[Alessandro Vesely]

On Mon 22/Aug/2022 23:53:16 +0200 Wei Chuang wrote:
All the while, using ARC as a framework may allow future support for 
another long standing issue, which is working on message modification while 
forwarding, in particular for mailing lists.  The proposal 
draft-kucherawy-dkim-list-canon-01 
 provides 
a framework for handling common mailing list modifications by identifying 
those modifications.  Putting it into ARC, may generalize this by 
identifying who made the modifications and be able to tolerate multiple 
such modifications such multiple mailing list expansions.



There doesn't seem to be interest in deeply reworking DKIM.

Another draft, draft-kucherawy-dkim-transform[*] proposed standard 
modifications.  I implemented (a variation of) it and it works about 50% of 
cases.  It fails when the original signature covers too many fields; for 
example, if one signs a MIME-Version field with a different capitalization, 
the mailing list will overwrite it and break the original signature for 
good.  Also, altering the order of To: or Cc: mailboxes breaks signatures 
irrecoverably, unless saving Original-To:, Original-Cc:, and any other 
signed field.


There are mailing lists that use ARC, but they also change From:.  ARC was 
thought for that case, but it is actually useful in different cases.


Also, cannot use ARC to fix the path through mailing list and forwarding 
scenarios.  That was attempted by draft-levine-dkim-conditional[†].


Best
Ale
--


[*] https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/
[†] https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

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

[Ietf-dkim] DKIM replay mitigations

[Wei Chuang]

Hi,
One of the known security challenges in DKIM is its vulnerability to replay
attacks as already mentioned in Security Considerations section 8.6
,
and has been raised at recent M3AAWGs as a significant challenge.  I'd like
to propose a couple of concepts for dealing with DKIM replay.  Depending on
where the conversation goes, I can get into proposals for technical
specification level proposals.

DKIM replay typically takes advantage of capturing a DKIM signed message
from the inbox and then rebroadcasting it out to many users.  Taking that
observation there are a couple of directions for mitigations.
1. We can try to detect and prevent the recipient amplification.  One way
may be to specify that the sender must always DKIM sign for the who the
intended recipient is including through mailing lists and forwarding
scenarios, in such a way that the receiver can check for this.  If the
intended recipient verification fails, then it may be an indication of
replay.  This must work for multiple forwarding hops and enterprise
scenarios, and when forwarders don't participate.
2. Distinguish signed messages in the inbox versus those in transit.  If we
see messages that were signed messages meant to be in the inbox, suddenly
in transit again, this likely indicates a replayed message.
3. Strengthen message digital signing to be replay resistant.  Currently
DKIM signature's identity just says it is associated with a particular
sender.  Perhaps we ought to tie the signature back to a particular SMTP
transaction by signing for both the sender, receiver and timestamp.  We
could add more specification around the timestamp to make it more workable
in the email distributed forwarding system for replay detection.  Put this
signature in a framework such as ARC that describes forwarding hops
better, so that receivers can make use of those identities with
forwarding.  Using ARC as the signing framework also helps proposal 1).
Again consider when receivers don't participate.  (This is a highly complex
scenario and likely I'm missing important details in trying to summarize)

All the while, using ARC as a framework may allow future support for
another long standing issue, which is working on message modification while
forwarding, in particular for mailing lists.  The proposal
draft-kucherawy-dkim-list-canon-01

provides
a framework for handling common mailing list modifications by identifying
those modifications.  Putting it into ARC, may generalize this by
identifying who made the modifications and be able to tolerate multiple
such modifications such multiple mailing list expansions.

Looking forward to your initial thoughts about feasibility and interest.
-Wei


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