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

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 9:23 PM Jesse Thompson  wrote:

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

As you cited, RFC 5322 describes three ways that the "Bcc" field is
typically used.  You're talking about just one of those, and I'm not sure
it's the most common one.  In any case, I suggest that "should" is a bit of
a leap, especially given that the choice of which of the three to use is
described as "implementation dependent".

The second part of your citation confirms the risk to which I was referring.

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

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

[Jesse Thompson]

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

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

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

...

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

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

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

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

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

[Jesse Thompson]

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

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

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

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

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


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

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

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

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

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch  wrote:

> If there are not that many BCC recipients for a message then it is likely
> not necessary as the duplicate message counting is unlikely to have a
> negative impact. If there are a large number of BCC recipients for a given
> message then I think the solutions proposed in Wei's DARA draft are
> helpful: standardizing the way to indicate BCC/Forwarded-To and signing a
> separate copy of the message for each BCC recipient so that it can still be
> verified as direct mail.
>

Doesn't putting "invisible" recipients into an actual field like Bcc create
a privacy concern, i.e., they're no longer invisible?  You need to hope
that the agents in the handling chain that are supposed to delete that
field will actually do it, which presumes the entire deployed base will
adopt DARA in a reasonable period of time.

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

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

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 7:43 PM Jesse Thompson  wrote:

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

Isn't this a derivative of the "Count DKIM signatures" approach identified
in the current problem statement document?  If so, do you have any comments
on the points against such an approach?

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

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

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

[Emanuel Schorsch]

On Sun, Aug 6, 2023 at 10:23 PM Jesse Thompson  wrote:

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

In my opinion, it seems like one nice solution would be to offer a way for
a sending domain to specify the expected SPF that should go with a DKIM
message (e.g. maybe an additional DKIM field). Then any domain that is
negatively affected by DKIM Replay could adopt this solution. ESPs might be
a particularly good use case if by default they use the same SPF for many
different customers. Though of course if this isn't possible, a simple
solution is to keep the number of BCC recipients for the same message to a
reasonable limit.


> 2) The actual recipient is included in the DKIM signed message (non-BCC).
>
>
> For messages which are originally submitted as BCC and, depending on the
> circumstances, it's necessary for us to identify the recipient in the
> headers, what is/should be the standard header to use for this purpose?
> BCC? Forwarded-to?
>

If there are not that many BCC recipients for a message then it is likely
not necessary as the duplicate message counting is unlikely to have a
negative impact. If there are a large number of BCC recipients for a given
message then I think the solutions proposed in Wei's DARA draft are
helpful: standardizing the way to indicate BCC/Forwarded-To and signing a
separate copy of the message for each BCC recipient so that it can still be
verified as direct mail.

I think the most likely to have a negative impact from Duplicate Message
Counting is mailingLists and ListExpanders. But I would love to hear more
areas where this would have challenges! For mailingLists as long as they
use a MailingList DKIM signature there shouldn't be issues. For
MailingLists that don't modify the content and don't use their own DKIM
signature it might be tricky. This is where more involved solutions would
be needed like the ones Wei proposes.
___
Ietf-dkim mailing list

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

[Jesse Thompson]

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

I'll need to read up on these.


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

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

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

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

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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Scott Kitterman]

On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman 
> 
> wrote:
> > On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
> > ...
> > 
> > > (2) Throughout the document, the proper term "Replay Attack" (and
> > 
> > sometimes
> > 
> > > "Replay") is used, but it's never directly defined.  I don't think you
> > 
> > need
> > 
> > > it to be formal, but if you really want to do it that way, please add a
> > > definition for it.
> > 
> > ...
> > 
> > I think a definition that describes a condition that's technically
> > distinguishable from normal DKIM operations is essential if we are going
> > to
> > make any progress.  "I know it when I see it" may work for the US Supreme
> > Court, but it's not adequate here.
> 
> I think the document does describe the attack.  An instance of the attack
> is when a replayed message lands someplace it wasn't originally intended to
> land, assuming normal usage.
> 
> The document also describes that the payload itself in normal usage is
> indistinguishable from an instance of the attack; the obvious implication
> is that there's no solution based solely on the payload format.
> 
> Your point that we possibly can't go much further than that is one for the
> WG to deliberate, to be sure.  And I suggest that that's one possible
> outcome of this WG.
> 
> But my point above is simpler: "Replay Attack", when capitalized that way,
> has me going to look for a formal definition of that term someplace.  That
> is, if we're going to use it that way, we should define it that way.  So,
> just add it to the Glossary at least, or say in Section 1.1 that this term,
> in this document, means the attack described by that section.  Or something.

I see your point.  Thanks,

It will be interesting to see what develops.  It's not a mystery that I'm 
skeptical of a protocol solution to the issue.

Scott k


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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Murray S. Kucherawy]

On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman 
wrote:

> On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
> ...
> > (2) Throughout the document, the proper term "Replay Attack" (and
> sometimes
> > "Replay") is used, but it's never directly defined.  I don't think you
> need
> > it to be formal, but if you really want to do it that way, please add a
> > definition for it.
> ...
>
> I think a definition that describes a condition that's technically
> distinguishable from normal DKIM operations is essential if we are going
> to
> make any progress.  "I know it when I see it" may work for the US Supreme
> Court, but it's not adequate here.
>

I think the document does describe the attack.  An instance of the attack
is when a replayed message lands someplace it wasn't originally intended to
land, assuming normal usage.

The document also describes that the payload itself in normal usage is
indistinguishable from an instance of the attack; the obvious implication
is that there's no solution based solely on the payload format.

Your point that we possibly can't go much further than that is one for the
WG to deliberate, to be sure.  And I suggest that that's one possible
outcome of this WG.

But my point above is simpler: "Replay Attack", when capitalized that way,
has me going to look for a formal definition of that term someplace.  That
is, if we're going to use it that way, we should define it that way.  So,
just add it to the Glossary at least, or say in Section 1.1 that this term,
in this document, means the attack described by that section.  Or something.

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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Scott Kitterman]

On August 7, 2023 11:10:07 PM UTC, Dave Crocker  wrote:
>On 8/7/2023 3:58 PM, Scott Kitterman wrote:
>> I think a definition that describes a condition that's technically
>> distinguishable from normal DKIM operations is essential if we are going to
>> make any progress.
>
>Except that the draft notes that isn't possible.
>
>There's a fair amount of text in 1.1 that seeks to describe the nature of a 
>Replay attack, and distinguish it from 'normal' behavior as best as we can.
>
>A better, more objective and precise definition would be great. Please also 
>provide one for spam.
>
>If someone has actual substance to offer, to improve 1.1, please, please, 
>please do offer it.
>
>d/
>
>ps.  Unless it isn't clear what existing draft text I'm referring to:
>
>> During development of the DKIM specification, DKIM Replay was identified as 
>> only of hypothetical concern. However, that attack has become commonplace, 
>> particularly for systems:
>> 
>>  *
>> 
>> Attackers create, obtain access, or compromise an account at some
>> Originator that signs messages with DKIM
>> 
>>   * Attackers locate a Receiver that consumes DKIM to make a delivery
>> decision. If the Receiver uses a reputation system with DKIM for
>> delivery decisions, the attacker finds an Originator with a high
>> reputation.
>>   * They send an email from that account to an external account also
>> under their control.
>>   * This single message is delivered to the attacker's mailbox, giving
>> them an email with a valid DKIM signature, for a domain with high
>> reputation.
>>   * They then post the message to a new and large set of additional
>> recipients at the Receiver.
>> 
>> Internet Mail permits sending a message to addresses that are not listed in 
>> the content To:, Cc: or Bcc: header fields. Although DKIM covers portions of 
>> the message content, and can cover these header fields, it does not cover 
>> the envelope addresses, used by the email transport service, for determining 
>> handling behaviors. So this message can then be replayed to arbitrary 
>> thousands or millions of other recipients, none of whom were specified by 
>> the original author.That is, DKIM Replay takes a message with a valid DKIM 
>> signature, and distributes it widely to many additional recipients, without 
>> breaking the signature.
>> 
>>   * Further, a message used in a Replay Attack has the same attributes
>> as some types of legitimate mail. That is, an individual, replayed
>> message has no observable differences from a legitimate message.

Then I guess I don't know what we're doing.

Solve a problem with a protocol change when the protocol can't tell the 
problematic case from normal usage seems like either the shortest working group 
ever or the longest.

I would agree that there's a description of what's happening that is considered 
bad, but that's not the same thing as a technically distinct definition.

Scott K

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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Dave Crocker]

On 8/7/2023 3:58 PM, Scott Kitterman wrote:

I think a definition that describes a condition that's technically
distinguishable from normal DKIM operations is essential if we are going to
make any progress.


Except that the draft notes that isn't possible.

There's a fair amount of text in 1.1 that seeks to describe the nature 
of a Replay attack, and distinguish it from 'normal' behavior as best as 
we can.


A better, more objective and precise definition would be great. Please 
also provide one for spam.


If someone has actual substance to offer, to improve 1.1, please, 
please, please do offer it.


d/

ps.  Unless it isn't clear what existing draft text I'm referring to:

During development of the DKIM specification, DKIM Replay was 
identified as only of hypothetical concern. However, that attack has 
become commonplace, particularly for systems:


 *

Attackers create, obtain access, or compromise an account at some
Originator that signs messages with DKIM

  * Attackers locate a Receiver that consumes DKIM to make a delivery
decision. If the Receiver uses a reputation system with DKIM for
delivery decisions, the attacker finds an Originator with a high
reputation.
  * They send an email from that account to an external account also
under their control.
  * This single message is delivered to the attacker's mailbox, giving
them an email with a valid DKIM signature, for a domain with high
reputation.
  * They then post the message to a new and large set of additional
recipients at the Receiver.

Internet Mail permits sending a message to addresses that are not 
listed in the content To:, Cc: or Bcc: header fields. Although DKIM 
covers portions of the message content, and can cover these header 
fields, it does not cover the envelope addresses, used by the email 
transport service, for determining handling behaviors. So this message 
can then be replayed to arbitrary thousands or millions of other 
recipients, none of whom were specified by the original author.That 
is, DKIM Replay takes a message with a valid DKIM signature, and 
distributes it widely to many additional recipients, without breaking 
the signature.


  * Further, a message used in a Replay Attack has the same attributes
as some types of legitimate mail. That is, an individual, replayed
message has no observable differences from a legitimate message.



--
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] draft-ietf-dkim-replay-problem comments

[Scott Kitterman]

On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
...
> (2) Throughout the document, the proper term "Replay Attack" (and sometimes
> "Replay") is used, but it's never directly defined.  I don't think you need
> it to be formal, but if you really want to do it that way, please add a
> definition for it.
...

I think a definition that describes a condition that's technically 
distinguishable from normal DKIM operations is essential if we are going to 
make any progress.  "I know it when I see it" may work for the US Supreme 
Court, but it's not adequate here.

Scott K


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

[Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Murray S. Kucherawy]

Hi,

Some comments after a review of the adopted document:

(1) I find the abstract is more readable if broken into three paragraphs,
with the second starting "DKIM survives ..." and the third "This document
discusses ...".

(2) Throughout the document, the proper term "Replay Attack" (and sometimes
"Replay") is used, but it's never directly defined.  I don't think you need
it to be formal, but if you really want to do it that way, please add a
definition for it.

(3) The first sentence/paragraph of Section 1 isn't necessary.

(4) The last paragraph of Section 1 refers to the "DKIM domain" but I don't
think this is defined anywhere.  It's also not clear that if the signature
doesn't validate, there is no output from DKIM in terms of an authenticated
identifier.  Maybe "DKIM-authenticated domain"?

(5) In Section 1.1, "The presence of a validated DKIM signature" begins two
sentences.  I suggest some wordsmithing here.

(6) In Section 1.1, the sentence ending "particularly for systems" reads
funny.  I suggest: "However, that attack has become commonplace, and
typically manifests itself as follows:"

(7) In Section 1.1, for the first bullet, suggest:

"Attackers create, obtain access, or compromise an account at some
Originator that signs messages with DKIM, preferably one that has developed
a positive reputation;"

(8) Second bullet:

"Attackers locate a Receiver that consumes DKIM to make a delivery
decision."

(9) Third bullet:

"Attackers send an email from that account to an external account also
under their control."

(10) Fifth bullet:

"Attackers then post the message to a new and large set of additional
recipients at the Receiver."

(11) s/in the content/in the visible/

(12) De-bullet the "Further, a message used ..." paragraph.

(13) Define the term "re-posting flows", or give an example.

(14) Add "experimental" to the ARC reference.

(15) In Section 1.2, strike the "NOTE".  This is an Informational document
so this isn't necessary (and this way you can drop the BCP 14 reference).

(16) Also in Section 1.2, importing definitions from RFC 5598 verbatim is
not necessary and risks editorial drift; simply making the reference and
advising the reader to be familiar with it is sufficient.

(17) Also in Section 1.2 at the end, two things: (a) Mentioning that DKIM
is an authentication protocol used by the above described actors is, IMHO,
redundant; and (b) on review of the document as a whole, I don't think
mentioning SPF adds anything, so I suggest we consider removing it.

(18) In Section 2.2, we refer to "author".  If this should be "Author" as
defined in RFC 5598, be sure to capitalize it.  If we mean something else,
what?

(19) Also in Section 2.2 it talks about sending a different message.
Different how?

(20) Section 2.3 talks about an alias replacing the envelope sender.  Is
this true?  I don't think, for instance, that sendmail replaces the
envelope sender when it routes a message through an alias.

(21) In Section 3.1, the first paragraph is effectively a restatement of
Section 1.1.  Can we drop it?

(22) Also in Section 3.1, I suggest not mentioning "spam folder" as that's
one of any number of possible handling choices.  Maybe just talk about
"misclassification"?

(23) Also in Section 3.1, the last sentence seems to be redundant; I
suggest removing it.

(24) Sections 3.2 and 3.3 are too short to be their own sections, and end
the same way.  I suggest common factoring.

(25) Section 4 says things like "SMTP Envelope RCPT-TO", but we already
have a notation for this (RFC5321.RcptTo), which other specifications
related to DKIM use.  I suggest using those.

(26) In Section 5.1, s/original sending/original message/

(27) Section 5.1, first bullet:

"This prevents a valid signature from being replayed to destination
addresses not anticipated by the DKIM signer"

(28) Second bullet: s/ENVELOPE-TO/envelope recipients/, or use the notation
mentioned above.

(29) Section 5.2, "known DKIM signatures" needs a better definition; known
how?  Are we talking about the whole header field, or just the "b" value?

(30) Section 5.4, I remember mentioning at M3AAWG that RFC 6376 recommends
against using "x=" for replay mitigation. I also think there's been
evidence presented (I forget where) that enforcement of "x=" is not
universal, so it's not a reliable mitigation.  We should mention these.

(31) In Section 5.5, s/spec/protocol/ (two instances)

(32) Suggest replacing Section 6 with:

"Readers interested in this problem space should already be familiar with
the Security Considerations described in [RFC6376].  The problem described
in this document amounts to a privilege escalation attack against email
content filters.  Mitigation or solution documents may follow."

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

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

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20230807170617.91_dg%stef...@sdaoden.eu>:
 |Jeremy Harris wrote in
 | <25aead67-8b9f-1db0-076d-12620a394...@wizmail.org>:
 ||On 07/08/2023 05:22, Jesse Thompson wrote:
 ...
 |ML-specific headers).  That is, enable restoration and DKIM
 |checking of the original, pre-modified message.
 |This re-enables proper SPF checking, at least during DKIM

Even better, drop SPF.  I mean, i cannot help it.  If someone puts
an envelope around my letter, and another one puts another one,
etc., as long as the original content can be restored, and
presented "as-written", i do not care about anything else.
One may even invent an "SPF-like entry to DKIM", and allow
flagging, like in that Levine draft, that the message may indeed
come modified (by a mailing-list).  Or, surely more importantly to
some, that this may _not_ be allowed.
One could consider to put such in DNS in conjunction with
_domainkey.

In truly human societies (native jungle habitants without written
language that is, of course), people are sent out to the villages
with words of and by "the king", and then scanned and accepted by
the village habitants.  The light is enough.  (I do not want to
know what happens upon reputation scan failure.)

 |verification, and could thus restore mailing-list operation as was
 |known for decades, unless i am mistaken.  (In an all-DKIM world.)

Speaking of native jungle habitants, i wonder whether it is
sufficient to only have bh=.  How well does DKIM handle (looking
at opendkim/tests, they do not test at all) if messages are torn
into pieces, aka their MIME layout is completely changed?  They,
you would have

  advertising 1
  /alternative of original mail plain/html
  ad 2
  attachement 1 of original mail
  ad 3
  att 2 ..

Shouldn't that be extended so that each and every part (except for
alternative, but then one must be aware of things like

  /alternative
plain
/mixed
  html
  pic 1
  x y

not to talk about /related and all sorts of things there etc etc.
Shouldn't each MIME part have a Content-ID, and shouldn't it be
made possible that DKIM links c-id<>checksum, and one could make
that excessively complicated and overly detailed now?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

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

[Steffen Nurpmeso]

Jeremy Harris wrote in
 <25aead67-8b9f-1db0-076d-12620a394...@wizmail.org>:
 |On 07/08/2023 05:22, Jesse Thompson wrote:
 |> For messages which are originally submitted as BCC and, depending \
 |> on the circumstances, it's necessary for us to identify the recipient \
 |> in the headers, what is/should be the standard header to use for \
 |> this purpose? BCC? Forwarded-to?
 |
 |There is no such header.  That's the whole point of a bcc; it's Blind.
 |If there was one it would have to be a separate message to the one \
 |it is a copy of.

That was where Dave Crocker's per-RCPT-TO comes in.
I did not know about draft-levine-dkim-conditional before, but
what is wrong with extending DKIM as such, instead of having all
those other things like DMARC etc.

You could include some more tags in the DKIM signature, one that
signals that another per-receiver DKIM signature MUST be present
(in an "outer envelope", ie, in a line that passed aka already
having been read when this one is seen), a special one that
correlates a RCPT-TO to the checksum/xy of the full DKIM currently
processed.  A minimized variant.

You could define a DKIM specific ML header that takes some fields
and their bodies from the pre-resent message (maybe compressed,
surely base64 encoded to make them joinable to a comma-separated
list), and MUST include that in the DKIM signature.  (So receivers
can restore the original content of said headers, and compare it
against the (still included) DKIM signature of an "inner envelope"
(presuming that new headers in the outermost envelope continue to
simply be prepended; of course some other headers are mixed or
suffixed, mailing-list software often does this for the
ML-specific headers).  That is, enable restoration and DKIM
checking of the original, pre-modified message.
This re-enables proper SPF checking, at least during DKIM
verification, and could thus restore mailing-list operation as was
known for decades, unless i am mistaken.  (In an all-DKIM world.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Barry Leiba]

> I wasn't sure if I-Ds should set up normative references.  Based on the 
> comments I'm guessing that I should
> have.  I can make a pass to fix all that.

Yes, sure they should.  Things that have to be understood in order to
understand the I-D are normative.  Things that just give additional
information but aren't necessary reading are informative.

Barry

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Barry Leiba]

> By all means, let's make this a cesspool of irrelevant junk. Especially for 
> junk that clearly has no clue about the
> history of DKIM.

Mike, that's out of line; please stop that sort of characterization.

Barry

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

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

[Jeremy Harris]

On 07/08/2023 05:22, Jesse Thompson wrote:

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


There is no such header.  That's the whole point of a bcc; it's Blind.
If there was one it would have to be a separate message to the one it is a copy 
of.
--
Cheers,
  Jeremy

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

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

[Alessandro Vesely]

On Sun 06/Aug/2023 18:07:15 + Jesse Thompson wrote:

On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:

[...]

The replay attackers aren’t sending what we commonly think of as spam 
through the signers - as the message is sent to one recipient (not 
bulk) and it is opt-in (that recipient wants and has asked for the 
mail). >
This is accurate from my observation. It takes only a single message which 
evades content filters, and the attacker is the first recipient, who will 
not report it as abuse.


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



Good question!  They could implement RFC 7073 to exchange information based 
on, say, the RFC5322.From field of the messages.


Let me contrast that idea with a small mailbox provider's POV.  Stock IMAP 
server packages provide no tools to reckon users' liking of messages. 
Reporting messages as spam also needs non-standard extensions.  (There is a 
proposal to signal basic reaction to a message, RFC 9078, but it's not 
implemented).



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


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



That would imply you know in advance that a message is going to be 
replayed.  Having that knowledge, like when you send to a mailing list, you 
can require that the replayer's signature be also present.  It wouldn't 
suit the problem at hand.



Best
Ale
--






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