Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy 
wrote:

>
> I've synthesized the feedback to date into a new update to the charter
> text.  It calls out the order of operations the group seems to prefer, and
> makes explicit the possible output of a "best practices" update.  Let me
> know if this is a step in the right direction or the wrong one.
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>
> Note that the next IESG telechat with room on it won't be until the new
> year at this point, so this won't advance before then.
>

Having heard no further feedback, I've moved the draft charter to the next
state, which will trigger the first of two IESG reviews early in the new
year.  It will go out for full IETF review after it passes the first of
those.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Tue, Dec 13, 2022 at 5:00 PM Michael Thomas  wrote:

> On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:
>
>
> This tactic appears to me to have three problems: (1) negative reputations
> are of little value to receivers, because attackers can easily shed them;
> (2) if I have to remember everything with a negative reputation for some
> undetermined period of time, I now have a resource problem; (3) I can just
> not sign my mail, because maybe no reputation is better than a negative one.
>
> I don't understand #1. As in they can move to another service? Or what?
>
Right.  IP address gets a bad reputation?  Move to another one.  Domain
blocklisted?  Register another one.  etc.  Any bad reputation is trivially
exchanged for a neutral one.  That leaves us in a world where only positive
reputations are meaningful, and presumably once you have one you'll work to
protect it.

> As for 3, it's pretty easy to cons up a new domain with fresh neutral
> reputation and still enjoy the supposed benefit of mail being signed for
> awhile. If you factor SPF in though it probably gets harder because now you
> need not only a new domain, but the underlying network connectivity to
> avoid detection.
>
Yep, but if a receiver values DKIM more than SPF, for instance, then maybe
they're willing to forgive that lack of support.  Maybe the forwarding
problem bugs you enough that you're forced into such a position, for
instance.

>  Which brings up a question: even though they pass on DKIM they should
> fail on SPF, right? For transactional email that seems like a big old red
> flag, right?
>
Yes, but that doesn't work for all applications or flows.  It depends on
what tolerances work for your use case and your users.

> In both cases you need to keep track of both as somebody with a bad rep
> might get better and one with a good rep might get worse, right? That is,
> this isn't static. Preferential of course is pretty subjective. I suspect
> that most of these filters operate much like spamassassin which gives
> weights to various factors, so good and bad are both useful.
>

Sure but on my email, I would like you to have only positive signal, to the
extent I can control that.  Or, at least, as little negative signal as
possible.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Tue, Dec 13, 2022 at 2:54 AM Alessandro Vesely  wrote:

> Perhaps they could devise better methods than asking _accountable? (Y/N)_
> on a
> questionnaire.  Linking to bank accounts is an example.
>

Would you link a free email account to your bank account for any reason?  I
don't think I would.  I'll go somewhere else.

A discernment possibility is to sign differently.  RFC 6376 specified an
> Agent
> or User Identifier tag, i=, as a finer grained identity.  One having
> i=bullshit...@example.com would still be a valid DKIM signature.
> Alternatively, could use subdomains, d=bullshit.example.com.  How long
> would it
> take receivers to learn it?
>

This tactic appears to me to have three problems: (1) negative reputations
are of little value to receivers, because attackers can easily shed them;
(2) if I have to remember everything with a negative reputation for some
undetermined period of time, I now have a resource problem; (3) I can just
not sign my mail, because maybe no reputation is better than a negative one.

In contrast, positive reputations are far fewer in number, far more
valuable to collect and protect, and very likely last a lot longer.  Giving
preferential treatment to a domain that earns a positive reputation seems
like a much better approach.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Mon, Dec 12, 2022 at 12:36 PM Michael Thomas  wrote:

> I have good reason to be suspicious. That Google was one of the major
> proponents of ARC which was supposedly to deal with the mailing list
> problem but all boiled down to reputation that could already be done with
> plain old DKIM suggests that reputation remains an unsolved problem. Maybe
> it is just one side of the company not knowing what the other side knows,
> but I find that rather unlikely. So there is a contradiction somewhere
> here from where I sit.
>

I would be unsurprised if the consensus is indeed that reputation is an
unsolved problem.  There's no DKIM-based public reputation service that I
know of; it remains the secret sauce of large operators with the resources
to gather enough data to compute such a thing, and they have little
incentive to share.  I did enough experimentation years ago to conclude
that such a thing would be possible to build, but the need for reliable
data sources and the upkeep effort were both significant.

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

Re: [Ietf-dkim] Taking Responsibility

[Murray S. Kucherawy]

On Mon, Dec 12, 2022 at 5:03 PM Michael Thomas  wrote:

> Note that in both cases it requires the good will of the receiver (or
> client in the web case). We already have the equivalent of expired certs
> with the x= option. If senders are concerned about this, there is
> already solution in the current specs.
>

At a recent meeting where I heard some mass senders talk about this
problem, the use of "x=" as a mitigation technique was raised.  I was
curious to know what their experience was in terms of (a) success overall,
but also (b) how broadly they found "x=" to have been properly implemented
by receivers.  I have to admit that was some months ago and now I forget
the answer; maybe someone else who was there can fill in that blank.

But I'm not sure that "x=" by itself is enough, given that it takes only a
matter of seconds for the attack to succeed, and it seems unlikely to me
that the "t=" and "x=" values would ever be that close together.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas  wrote:

> But I want to return to my previous point of whether reputation is even
> quantifiable, and whether somebody has actually gone out and researched it.
> We can say that this is a problem in theory, but do we have any data to
> back it up? I kinda think that should be table stakes before talking about
> rechartering.
>

The industry appears to think it's a factor.  This work comes to us from
M3AAWG where there's a critical mass that believes reputation abuse of this
nature is real.  Though I agree it would be helpful to have metrics to
describe it more precisely, it's my perception that there's enough momentum
here to back chartering.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely  wrote:

> > The alternative is to say: Well, if you can't make at least one of those
> > two quantities bulletproof, then don't sign your mail.  That, though,
> > sounds a lot to me like tossing DKIM in the bin.
>
> On the opposite, if Gmail restricted signing to accountable users only,
> its
> signatures would gain value.  If they started doing so it would soon be
> noticed, and signatures would acquire a meaning in delivery decisions.
>

Is the cost of imposing a program that vets every user comparable to that
of the damage caused by this attack vector?  My impression is that it is
not.

Endowing signatures with a significant value increases the overall value of
> DKIM.
>

Presumably they already have significant value.  That's why this attack
works already.

The question is whether we should proclaim that the bar needs to be even
higher, maybe even an all-or-nothing proposition.  I'm suggesting that's
not a good idea.

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Thu, Dec 8, 2022 at 11:52 AM Jim Fenton  wrote:

>
> >> I think a checkpoint / review is a good goal for the group.
> >>
> >
> > This seems like something reasonable and easy to add.
> >
> > Any objections?
>
> I’m fine if the revision to best practices is scoped to the replay
> problem. This was presented to dispatch as a narrowly scoped problem
> statement, and the rechartering result was decided on that basis. If this
> were to evolve into a “let’s think about DKIM best practices” more
> generally, it will get bogged down.
>

I've synthesized the feedback to date into a new update to the charter
text.  It calls out the order of operations the group seems to prefer, and
makes explicit the possible output of a "best practices" update.  Let me
know if this is a step in the right direction or the wrong one.

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Note that the next IESG telechat with room on it won't be until the new
year at this point, so this won't advance before then.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

(Apologies for top-posting while mobile)

There's ample legitimate use of Bcc or equivalent such that I have trouble
believing the rules you're talking about here can be taken as universally
valid.

Mailing lists or even multi-recipient aliases are additional examples.

And since DKIM is (currently, at least) decoupled from the envelope, I
think we're also taking across layers here.

-MSK

On Sun, Dec 11, 2022, 14:46 Michael Deutschmann  wrote:

> On Sun, 11 Dec 2022, Murray S. Kucherawy wrote:
> > Then from that other account I can spray it to as many recipients as I
> > want so long as the only thing I change is the envelope.
>
> Since the ISP is doing the signing, you can't stop them from using a
> signature that protects the To: and Cc: from modification, and in practice
> everyone already does that.  That means the bonus messages you get to
> send via the hack will have mismatched 822 and 821 recipients, equivalent
> to a blind-carbon-copy.
>
> Blind-carbon-copy is already a sign of spam.  Long ago, it was because the
> bad guys were using open relays, and could spam faster by issuing many
> RCPT TO:s to the relay in one transaction.  (I remember being puzzled
> back then that most of my spam came "To: fri...@public.com" rather than
> my address at the time.).
>
> In modern times, you still see it from "Nigerian" scammers who seem to be
> using real webmail sites and copy-pasting huge address lists into a
> literal Bcc: field.
>
>  Michael Deutschmann 
>
> ___
> 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] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 1:55 PM Murray S. Kucherawy 
wrote:

> In the transaction where the signature is applied, there's only one
> envelope recipient.  When I'm executing the attack, I could do one envelope
> per recipient if I'm worried about being detected that way.
>
> If Message-ID isn't covered by the header hash, it can be unique per
> envelope.
>
> There was a suggestion that the "bh=" could be required to be unique per
> MX to avoid replays, but that becomes a potentially gigantic hash table, so
> now there's a resource problem imposed on the receiver/verifier.  Even if
> you key it on Message-ID, you have the same resource problem.
>

Also, a deduplication defense is only effective if the replay campaign
touches the same MX more than once.  There's still a benefit if I avoid
that; there are zillions of distinct MXes out there, and federation is
probably not common enough to make a dent.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 1:41 PM Michael Thomas  wrote:

>
> But the BCC aspect is interesting too. Don't providers already view things
>> with massive rcpt-to (bcc's) suspiciously?
>>
> That's easy to evade: Send a spam message to yourself only.  That has the
> signature.  Now capture that from your inbox and replay it from a different
> server to any number of recipients, using any number of envelopes, to your
> heart's content.  Won't pass SPF, but it passes DKIM.  If the receiver
> values DKIM more, or only cares if one passes, you win.
>
> No, I mean that the if number of RCPT-TO's is large, it's suspicious. Even
> if they do individual SMTP transactions it will have the same (signed)
> Message-Id so that's not evadeable either in theory.
>
In the transaction where the signature is applied, there's only one
envelope recipient.  When I'm executing the attack, I could do one envelope
per recipient if I'm worried about being detected that way.

If Message-ID isn't covered by the header hash, it can be unique per
envelope.

There was a suggestion that the "bh=" could be required to be unique per MX
to avoid replays, but that becomes a potentially gigantic hash table, so
now there's a resource problem imposed on the receiver/verifier.  Even if
you key it on Message-ID, you have the same resource problem.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 1:11 PM Michael Thomas  wrote:

>
>
> As for resolution: the first obvious one is to not send spam in the first
>> place. That is the root of the problem. The second is that Bcc's can be
>> treated with more suspicion. Neither of these needs the working group to do
>> anything.
>>
>
> I think this is easier said than done.  In the example I gave, "don't send
> spam in the first place" reduces to "make sure your users are 100%
> trustworthy or that your outbound spam filters are 100% accurate", which
> strikes me as an impossible bar to meet.
>
> I'm going to assume that the attackers will need to iterate to find a
> piece of mail that passes their filters. That is signal right there that
> abuse is likely. Perhaps an exponential backoff could be employed when
> outbound spam is detected. Sort of like a 4xx "try later".
>
That's easy to evade: Come from a rotating pool of IP addresses, using a
new free account each time.

> But the BCC aspect is interesting too. Don't providers already view things
> with massive rcpt-to (bcc's) suspiciously?
>
That's easy to evade: Send a spam message to yourself only.  That has the
signature.  Now capture that from your inbox and replay it from a different
server to any number of recipients, using any number of envelopes, to your
heart's content.  Won't pass SPF, but it passes DKIM.  If the receiver
values DKIM more, or only cares if one passes, you win.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas  wrote:

> Re: stripping signatures, all the attacker needs to do is either send it
> to a service that doesn't strip signatures or use their own MTA. Trivially
> avoidable, and a Maginot Line of epic narrowness.
>

Right, I think this is an aspect of that proposal that warrants further
debate.  I think the argument is compelling, but it's clearly not
bulletproof.


> As for resolution: the first obvious one is to not send spam in the first
> place. That is the root of the problem. The second is that Bcc's can be
> treated with more suspicion. Neither of these needs the working group to do
> anything.
>

I think this is easier said than done.  In the example I gave, "don't send
spam in the first place" reduces to "make sure your users are 100%
trustworthy or that your outbound spam filters are 100% accurate", which
strikes me as an impossible bar to meet.

The alternative is to say: Well, if you can't make at least one of those
two quantities bulletproof, then don't sign your mail.  That, though,
sounds a lot to me like tossing DKIM in the bin.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sat, Dec 10, 2022 at 7:42 PM Michael Deutschmann 
wrote:

> It's a bit annoying that after almost two weeks, the only responses in
> this thread have been about this side issue, with my main point
> unaddressed.
>

As I read your original post, it was about DKIM+DMARC being an anti-forgery
tool, not an anti-spam tool.  While that may be true, what's being
discussed is the replay attack involving DKIM irrespective of DMARC.

DKIM's not an anti-forgery tool by itself.  The domain in the "d" tag
doesn't have to be the same as the domain in the From field for a signature
to be valid.  The problem being brought to this community is that replay --
which in 2011 we didn't think would be a big deal -- has apparently become
a problem.  The focus is dealing with this in DKIM, if possible,
irrespective of how it might impact DMARC.

Since the focus of your original post seemed to be at a level above where
DKIM does its work, I thought it was unrelated to the problem being
discussed.


> If your configuration is not Baka, then you have nothing to fear from the
> replay attack.   The replay attack only allows an attacker to pretend to
> *continue* to own an e-mail address they just lost; it never lets them
> impersonate someone who already has a good reputation.
>

Pop culture references aside, I don't follow this.  If I send a piece of
spam from this account to another, it will be signed by Gmail (assuming
their filters pass it).  Then from that other account I can spray it to as
many recipients as I want so long as the only thing I change is the
envelope.  The signature remains intact, and its delivery to those domains
checking such things will be predicated on the validity of that signature.
I haven't "lost" my email address; I can repeat this attack as many times
as I want.  And I (via Gmail) have a globally good reputation.  This is the
concern that I understand is being discussed.

If you are Baka but apply a downscore for blind-carbon-copy of
> equal-or-greater magnitude than your Baka upscore, you are also immune to
> the replay attack.  But you will still be wide open to other spammers.
>

First, if this is the advice verifiers/receivers should be applying, then
it would be a good idea to write it down someplace so it can be found.  I
don't know that this has been done yet.  Has it?

Second, how would one establish "magnitude" given that the final recipient
has no idea what the original envelope looked like?

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

Re: [Ietf-dkim] Taking Responsibility

[Murray S. Kucherawy]

On Fri, Dec 9, 2022 at 7:08 PM Barry Leiba  wrote:

> I have no formal role here, so please just take this as a plea from a
> participant:
>
> Let's please stop bickering: it's simply hindering a productive
> discussion of a charter, and it's clear that we can have endless
> back-and-forth messages in this vein for quite some time if we let
> ourselves.  Please, let's not let ourselves.
>

I concur.  The bickering has resulted in a growing string of people who are
not willing to chair the reconstituted working group because this is what
they'd have to spend time dealing with.  As a result, this work will not
get off the ground if these impulses cannot be controlled.

If necessary, this list can be made into a moderated one, which will
significantly slow the dialog as things must wait in the moderator queue,
with holidays and vacations imminent.  Please let's not be forced in that
direction.

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Thu, Dec 8, 2022 at 12:56 AM Laura Atkins 
wrote:

>
> Fair enough.  Does the charter need to say that a revision to best
> practices, relative to the replay problem, might be a possible output?
> It's within the realm of possibility that no protocol work comes out of
> this, but a "checkpoint" about current realities might be good to publish
> in that case.
>
>
> I think a checkpoint / review is a good goal for the group.
>

This seems like something reasonable and easy to add.

Any objections?

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker  wrote:

> As appealing as the AS concept is, I've never been clear how operationally
> useful they are.
>
> More to the current point, if the anti-replay work to be done benefits
> from a position on transit vs. non-transit, then including it directly in
> an anti-replay specification would be more helpful than in a separate AS.
>
Fair enough.  Does the charter need to say that a revision to best
practices, relative to the replay problem, might be a possible output?
It's within the realm of possibility that no protocol work comes out of
this, but a "checkpoint" about current realities might be good to publish
in that case.

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Tue, Dec 6, 2022 at 4:20 PM Dave Crocker  wrote:

> DKIM was developed to facilitate delivery handling decisions.  The
> language in the RFC 4871 and RFC 6376 doesn't make this as explicit as I'd
> wish, given the perspective I'm advocating, but it's got some implicating
> language.  References to validation by MTAs or MDAs obviously has to do
> with transit or delivery, and not after.  Reference to MUAs might imply
> long-term term.  Or not.  Certainly there is no discussion about long-term
> use of the signature.
>

Yes, it's definitely true that the standard was written from the
perspective of delivery-time evaluation, and then sending that result to
MUAs rather than having MUAs actually do the evaluation.  So although 4686
says that's a design goal, 6376 sure doesn't have that flavor.

I don't see either RFC clearly "disagreeing" with the view that DKIM is for
> transit-related work.  That's contrary to Murray's assessment.  But again,
> the RFC doesn't make that limitation clear (enough, IMO), either.
>

Right, I think that's what I'm driving at.  And because of this, we can't
take "transit-time" as a given.

It is absolutely within the purview of the reconstituted WG to "fix" this
by clarifying using current operational realities and acquired experience.
An applicability statement, for instance, would not be out of the question.

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 3, 2022 at 12:20 PM Jon Callas  wrote:

> > On Dec 3, 2022, at 11:42, Dave Crocker  wrote:
> >
> > On 12/3/2022 11:35 AM, Jon Callas wrote:
> >> Agreed, and we need some other weasel word than "lightweight" because
> there are lots of people working on "lightweight" symmetric ciphers.
> Something like "appropriate"?
> >>
> >> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't
> need a signature that is secure for a year (or more), it needs one that is
> secure for somewhere between a minute and a week.
> >
> > transit-time, cryptographic authentication ?
>
> I like that.
>

I've edited in this change, minus "transit-time".  I acknowledge that this
is what Jon and Dave are saying was the intent all along, and I'm not
arguing the point, but RFC 4686 -- which presumably recorded what was our
consensus at the time, and which RFC 6376 references as foundational
material -- disagrees, holding out an additional possibility that no DKIM
document since then has dispelled.  I don't think we should ignore this
conflict; I think it's important to resolve and record that resolution, and
this revised perspective can be part of the document(s) this working group
produces.

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

I've placed what I believe is the text that is closest to consensus in the
datatracker:

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Please provide comments or criticism soon.  Once it appears to be stable
relative to this audience, I'll send it on its way for internal (IESG) and
then full IETF review.

Should you wish to serve as a co-chair, or nominate someone for that
position, please contact me off-list.

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
wrote:

> I would add mention of the problem statement draft.  I think it may turn
> out
> to be the most important of the ones we have now.
>

Do you mean: Mention it as a mandatory deliverable?

Should we still produce that document even if we conclude replay can't be
solved?


> I still think "compatible with DKIM's broad deployment" is too narrow.
> Also,
> I think it's one reasonable conclusion the group might reach is that the
> cure
> is worse than the disease and a resolution along the lines of "remove
> signatures during delivery" and "be more careful about what you sign
> because
> signing bad things will hurt your domain's reputation" may be the most
> appropriate approach.
>

Yes, I think it's always implied that a working group can throw in the
towel if consensus is to do that.  I've never seen it spelled out in a
charter that this is an available option, but we can make it explicit if
people feel doing so would help set the scope.


> How about instead of "The DKIM working group will produce one or more
> technical specifications that describe the abuse and propose
> replay-resistant
> mechanisms that are compatible with DKIM's broad deployment" we say "The
> DKIM
> working group will evaluate potential mechanisms to mitigate this attack
> and
> produce one or more technical specifications that describe the abuse and
> propose improvements which, consistent with compatibility with DKIM's
> broad
> deployment and general email protocols, will reduce the impact of replay
> attacks".
>

I think those say approximately the same thing, so I'm fine with either.

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

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker  wrote:

> On 11/27/2022 6:30 PM, Murray S. Kucherawy wrote:
> > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> > using a digital signature to associate a domain identity with an email
> > message in a secure way, and to assure receiving domains that the
> > message has
> > not been altered since the signature was created.  Receiving systems
>
> Again:  DKIM does not assure that the message has not been altered.  It
> assures only the covered portions of the message.
>
> That's not a small difference in data integrity protection.
>

OK, I'll add that in.


> > A DKIM-signed message can be re-posted, to a different set of
> > recipients, without
> > disturbing the signature's validity.  This can be used to confound the
> > engines that
> > identify abusive content.  RFC 6376 identified a risk of these
> > "replay" attacks, but
> > at the time did not consider this to be a problem in need of a
> > solution.  Recently,
> > the community has decided that it has become enough of a problem to
> > warrant being revisited.
>
> This does not provide any real understanding of how replay is
> accomplished.  And since it's easy to explain and doesn't take much
> text, I'll again encourage including that in the document that defines
> the nature of the problem we will be working on, namely the charter.
>

Doesn't the "A DKIM-signed message can be re-posted, ..." sentence do
that?  I pulled it from your suggested text for that very reason.  Maybe
add something to the second sentence making clear the roles in the attack?


> > The DKIM working group will produce one or more technical
> > specifications that
> > describe the abuse and propose replay-resistant mechanisms that are
> > compatible
> > with DKIM's broad deployment.  The working group may produce documents
> > describing
> > relevant experimental trials first.
>
> This draft doesn't include the 'preservation of installed base' cover
> text that Barry's had and I forgot to include in mine.  I think it's
> important.
>

I had intended "compatible with DKIM's broad deployment" to cover exactly
this.  Should I word it differently?

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

[Ietf-dkim] Rechartering

[Murray S. Kucherawy]

Hi folks,

Area Director hat on here:

The discussion Barry kicked off has been interesting, but it has strayed
(and mea culpa, in part, because the material is interesting) from the work
of discussing a charter.

I've set the stage for re-chartering in the system, and now we need some
charter text.  Dave and Barry submitted text, which I've synthesized into
what's below.  Let's keep this thread just to discussion the charter text;
if you want to continue to debate the technical solutions or problem space,
please start other threads or reply to the other existing ones.

Here's my run at a charter; please provide suggestions or comments, or tell
us if you think it's ready to go.  It's a variant of Barry's version with
parts of Dave's merged in.  I've kept the list of candidate documents as a
starting point; the WG doesn't actually have to use any of them if that's
where consensus lands.

But let's figure out consensus on a charter before we try to hammer out
consensus on solutions.

-MSK

--

Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
using a digital signature to associate a domain identity with an email
message in a secure way, and to assure receiving domains that the message
has
not been altered since the signature was created.  Receiving systems
can use this information as part of their message-handling decision.
This can help reduce spam, phishing, and other unwanted or malicious
email.

A DKIM-signed message can be re-posted, to a different set of recipients,
without
disturbing the signature's validity.  This can be used to confound the
engines that
identify abusive content.  RFC 6376 identified a risk of these "replay"
attacks, but
at the time did not consider this to be a problem in need of a solution.
Recently,
the community has decided that it has become enough of a problem to warrant
being revisited.

The DKIM working group will produce one or more technical specifications
that
describe the abuse and propose replay-resistant mechanisms that are
compatible
with DKIM's broad deployment.  The working group may produce documents
describing
relevant experimental trials first.

Current proposals include the following drafts:

 - draft-bradshaw-envelope-validation-extension-dkim
 - draft-chuang-replay-resistant-arc
 - draft-gondwana-email-mailpath
 - draft-kucherawy-dkim-anti-replay

The working group may adopt or ignore these as it sees fit.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Murray S. Kucherawy]

On Sun, Nov 27, 2022 at 6:01 PM Dave Crocker  wrote:

> On 11/27/2022 5:48 PM, Murray S. Kucherawy wrote:
>
> Post-delivery survival of the signature is not only not a goal, it is
>> arguably (or possibly demonstrably) a problem.
>>
>
> Can we say more about this if we're going to take that position?  A naked
> "not a goal" doesn't jive with RFC 4686, which explicitly says it is a
> goal, or at least that it was one.
>
> Hmmm.  Having looked through the RFC, for every occurrence of 'delivery',
> I don't see an obvious statement indicating it is a goal.
>
This is the citation I keep coming to, toward the end of Section 1.1:

   DKIM operates entirely on the content (body and selected header
   fields) of the message, as defined in RFC 2822
<https://www.rfc-editor.org/rfc/rfc2822> [RFC2822
<https://www.rfc-editor.org/rfc/rfc2822>].  The
   transmission of messages via SMTP, defined in RFC 2821
<https://www.rfc-editor.org/rfc/rfc2821> [RFC2821
<https://www.rfc-editor.org/rfc/rfc2821>], and
   such elements as the envelope-from and envelope-to addresses and the
   HELO domain are not relevant to DKIM verification.  This is an
   intentional decision made to allow verification of messages via
   protocols other than SMTP, such as POP [RFC1939
<https://www.rfc-editor.org/rfc/rfc1939>] and IMAP [RFC3501
<https://www.rfc-editor.org/rfc/rfc3501>]
   which an MUA acting as a verifier might use.

I take this to mean the MUA is intended to be able to do the verification,
or at least that was our thinking back then.  Personally, I don't remember
ever mentally considering DKIM to be a transport-only mechanism, but kind
of a lot's happened since then.

It's fine if we think this was in hindsight a bad posture to take, but we
should probably draw a line from there to here and give some explanation
that doesn't seem like we're arbitrarily contradicting ourselves.

> I /do/ see a reference to wanting DKIM evaluation to be at the MDA or
> MUA.  Saying MUA does, obviously, imply surviving past formal delivery.
> Hmmm...
>
The thing I'm noticing is that this is the only place (that I can recall)
where it's specific about which part of the ecosystem constitutes a
"Verifier".  That is, 4686 says the Verifier might be something using POP
or IMAP to look at a message in a mailbox.  Meanwhile, I'm quite certain we
wrote 6376 with MSAs and MDAs in mind since that's where the
implementations of the time were, even though I don't think we explicitly
said it must be thus.  As it turns out, we wrote a standard that can be,
and is, successfully applied in any of those places.

Going back to an earlier posting, I noted that a site that removes the
> signature as part of delivery could provide an option to retain it.
>

Making this only a recommendation certainly does have particular advantages.

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Murray S. Kucherawy]

On Sat, Nov 26, 2022 at 4:31 PM Dave Crocker  wrote:

> On 11/26/2022 3:20 PM, Barry Leiba wrote:
> > I will say that the use case that is broken by removing the signature
> > is the "re-send" case, where the MUA or some other post-delivery agent
> > (perhaps a sieve script) re-introduces the message with a different
> > RCPT TO but the same MAIL FROM and "From:".
>
> Post-delivery survival of the signature is not only not a goal, it is
> arguably (or possibly demonstrably) a problem.
>

Can we say more about this if we're going to take that position?  A naked
"not a goal" doesn't jive with RFC 4686, which explicitly says it is a
goal, or at least that it was one.

I guess that means it comes down to making an argument about what
experience has shown us: Does Barry's use case, plus the Thunderbird
plug-in use case, together carry more weight than the perceived problem
that replay causes?

Also, a reminder that the WG hasn't actually rechartered yet; maybe some of
these debates should wait until that's happened.

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Murray S. Kucherawy]

On Mon, Nov 21, 2022 at 2:01 PM Dave Crocker  wrote:

> On 11/21/2022 1:56 PM, Murray S. Kucherawy wrote:
> > I don't want to get into implementation discussions before we even
> > have a charter, but I'm curious about how this could be made effective.
>
> I'd count it as a simple tool that might have incremental benefit.
>
> Simply give guidance that an MDA SHOULD remove the DKIM signature,
> unless there is a local arrangement with the recipient not to.
> (Obviously the local detail could swap the default the other way.)
>
> I would expect anything more elaborate to be in the range of diminishing
> returns and, therefore, not worth the complexity, effort, etc.
>

Sorry, I was referring to Miles' suggestion about bulkiness detection
(i.e., taking some kind of action based on seeing the same signature
again), not the removal of signatures.

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Murray S. Kucherawy]

Hi Jon,

On Mon, Nov 21, 2022 at 4:07 PM Jon Callas  wrote:

> As another original author, it was hard for me to understand what this was
> talking about when the discussion first came up. I even considered replying
> to this thread asking something like, "isn't replay just sending the
> message again?" before I understood.
>
> I really like the guidance that an MDA SHOULD remove a DKIM signature. I
> have memories that we discussed just that even at the time, for a number of
> reasons.
>
> This is a fine solution to this problem. The replay issue just goes away
> if the header lines are removed.
>
> It also addresses my long-standing complaint that DKIM is not supposed to
> be a tracking and authenticity mechanism. Moreover, this is a much better
> solution to my complaint than anything anyone has come up with, including
> my eccentric foot-stamping about keys.
>
> Lastly, it also addresses the inevitable issue that we aren't thinking of
> today, but five years from now we're going to discover.
>
> Let's just do it. Let's advise to people that they remove the signature in
> their MDA. We don't even need an RFC for it (though we could do one), we
> just need some reasonable implementation.
>

Just for the sake of being complete, we should probably come up with
something to say about this, which is in RFC 4686, the DKIM "threats"
document:

   DKIM operates entirely on the content (body and selected header
   fields) of the message, as defined in RFC 2822
 [RFC2822
].  The
   transmission of messages via SMTP, defined in RFC 2821
 [RFC2821
], and
   such elements as the envelope-from and envelope-to addresses and the
   HELO domain are not relevant to DKIM verification.  This is an
   intentional decision made to allow verification of messages via
   protocols other than SMTP, such as POP [RFC1939
] and IMAP [RFC3501
]
   which an MUA acting as a verifier might use.


We actually seemed to like the idea, at least back then, that the signature
survives delivery so that it can be validated at any point later.

In terms of mechanism, if this is the consensus position, I imagine a small
"Updates" document could be produced to formally amend/extend the advice
present in RFC 6376.

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Murray S. Kucherawy]

Hey Miles,

On Mon, Nov 21, 2022 at 10:29 AM Miles Libbey 
wrote:

> - the (signed) Date: header would get further in the past the longer a
> replay is used, which would/could be a sign of misbehavior
>

I think this is a decent theory, but with automation, the delta between
"Date" and/or the signature timestamp and the first replay can be rather
small, certainly smaller than any reasonable first delivery window.  It's
basically the "x=" problem.


> - the message body would still be immutable, and thus subject to bulkiness
> detection (for instance tracking the signature's occurrences)
>

I don't want to get into implementation discussions before we even have a
charter, but I'm curious about how this could be made effective.

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Murray S. Kucherawy]

On Sun, Nov 20, 2022 at 11:08 AM Dave Crocker  wrote:

> On 11/11/2022 7:19 AM, Murray S. Kucherawy wrote:
> > I think you've hit on possibly the most interesting part of this: In
> > RFC 6376, we said "You're taking some responsibility for this
> > message... and oh, by the way, it could get replayed, and your claimed
> > responsibility extends to that case as well".  I don't know that we
> > underscored the latter very much then or since.
>
> At the time DKIM was first developed, we knew that replay was possible.
> It was deemed a lesser concern.  Back then.
>
> But the "by the way" that you've added was /not/ part of the thinking
> then and it occurs to me that a) no it was not and is not intended, and
> b) this might argue for *having MDAs remove DKIM signatures...*
>

As I read RFC 6376, we knew that relay was possible, and we said up front
the bit about "some responsibility".  We didn't take the stand at any point
that a replay absolved the signer of that (admittedly nebulous)
responsibility; indeed, there's no obvious way for a verifier to be able to
tell that the message was [not] replayed so as to give it different
treatment.  In fact, not knowing where the message is ultimately going,
what its content means, or how it will be consumed, is what compelled us to
make the responsibility nebulous in the first place.

Of course, that was 2011, and kind of a lot's happened since then.

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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Murray S. Kucherawy]

On Sun, Nov 20, 2022, 11:08 Dave Crocker  wrote:

> Seriously.  DKIM is intended as a transit-time mechanism.  When delivery
> occurs, transit is done.  So DKIM has done its job and can (safely?) be
> removed.


One of the informational RFCs the original working group produced discussed
this. A reason (maybe the reason) the envelope was not included in the
signed content was so that the signature could survive without an envelope,
meaning it could be retrieved from a mailbox and re-verified.

I don't know, though, if anyone does this regularly, but it's been shown to
be useful in some circumstances.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Mon, Nov 14, 2022 at 11:04 AM Laura Atkins 
wrote:

> Does it make sense to add in a brief discussion of ‘responsibility for the
> message'? As I see it, responsibility implies able to do something against
> the originator of the message or act to stop the message if it turns out to
> be a problem. If it’s your customer and the mail is going out over your
> network you can disconnect them. If the mail isn’t going out through your
> network, you have very little control and if you don’t have control can you
> really be responsible.
>

Personally, I'd be fine leaving this for the WG to debate rather than
settling it in the charter.  I think both positions are defensible.

RFC 6376 says "some responsibility"; it leaves open to discussion what that
really means.  I'm sympathetic to the idea that Gmail (for example) filters
outgoing stuff looking for spam, but also that this has always been a
tactical arms race, and something you consider spam might not in that
moment agree with what their detection stuff can identify.  Wei might argue
that their signature means "We attest that this passed through us, and we
did our best to make sure it was legitimate before it went out", than the
more absolute "We claim this is legitimate and we are willing to stake our
reputation on it" that some seem to infer.  The latter might even be
incentive to consider not signing anymore.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Mon, Nov 14, 2022 at 12:42 AM Scott Kitterman 
wrote:

>
> I don't think there's any point in pursuing solutions that require a human
> to read/understand anything about header fields.
>
> Having reviewed the proposals again, it seems like anything that actively
> makes replays harder without adding additional indirect mail flow failures
> amounts to a plan to document the flow of the email to provide additional
> signal for receivers to understand what's been replayed versus what's a
> normal indirect flow.
>
> I'm inclined to think that instead of specifying specific drafts to
> consider, the charter should point to the problem statement draft instead.
>

The drafts don't all have to be developed by the working group.  It's
traditional for the charter to offer some drafts as things to consider, as
starting points for discussion.  The working group can then choose to
adopt, all, some, or none of them.

I think it was Barry who mentioned that a problem statement could be in a
document that never gets published.  I believe we could also include a
problem statement in the charter itself, if it can be brief enough and
doesn't need examples and so forth to make its point.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Mon, Nov 14, 2022 at 12:26 AM Scott Kitterman 
wrote:

> Is compatibility with DKIM sufficient for  the charter or should there be
> broader language about compatibility with existing email architecture?
> I'm
> inclined to say "Yes", but I'm unsure about wording.


I also assume "Yes".  I'm having a hard time seeing a charter that allows
broad disruption just to solve this problem.

I would even suggest we don't have to say so, but it's probably a good idea
to mention it.

Similarly, at least one of them could lead to normal indirect mail flows
> being
> identified as replay attacks.  Is something specific needed about being
> compatible with existing email deployments more generally (beyond DKIM
> deployment compatibility) needed?  Once agian, I'd say "Yes", but am not
> sure
> how to word it.
>

I would say this falls under "don't allow for false positives"; I'm not
sure a charter needs to say something about that though.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Sat, Nov 12, 2022 at 7:32 AM Roland Turner  wrote:

> On 11/11/22 23:09, Murray S. Kucherawy wrote:
>
> More concerning to me: The IETF has previously taken the position that the
> market will figure out spam and phishing, and therefore consideration of
> protocol solutions should be deflected.  DMARC was the result.   I feel
> that we leave this to the market, and that industry, at our own peril.  I
> think we should give this a serious look before rejecting it outright.
>
> Are you able to state concisely why DMARC was a harmful outcome, assuming
> that's your intended meaning ("peril")? From my admittedly somewhat
> bystanderish perspective, DMARC looked like a great success, particularly
> after IETF repeatedly failing for more than a decade[1].
>
If you are an entity that uses direct mail flows as a large part of your
regular operation, you're probably happy with DMARC.

If you're the IETF or anyone else that makes prominent use of indirect
flows, you got burned by DMARC.  It doesn't take much looking around to see
the side effects and workarounds people have had to deploy to continue to
operate in a DMARC world.

Balance those two against each other and, at least as a standards person, I
lean squarely into a negative opinion.  I think it's reasonable to consider
a standard to have been successful when its deployment improves an area
without also damaging it.  DMARC doesn't qualify.  The whole reason the
DMARC working group was chartered is to make an attempt to address the
damage caused by the improper rollout of DMARC into mail flows where it
breaks far more than it fixes.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins 
wrote:

>
> The MP limits the volume of messages that a user can send out.  However,
> by signing even one message, it takes the responsibility for its content.
>
>
> This appears to be the disconnect. The MP takes responsibility for the
> *MESSAGE* - that message, sent to that user.
>

I think you've hit on possibly the most interesting part of this: In RFC
6376, we said "You're taking some responsibility for this message... and
oh, by the way, it could get replayed, and your claimed responsibility
extends to that case as well".  I don't know that we underscored the latter
very much then or since.

So to me, part of this hinges on whether we feel we need to remedy that, or
be comfortable pointing at 6376 and telling people to read it again,
properly this time, and seeing if the industry is OK with that.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman 
wrote:

> > A heuristic I’ve suggested previously is “If the recipient’s email
> address
> > is not in the To: or Cc: header then treat the mail as unsigned”.
>
> Which is a fancy way of making DKIM only work for direct mail flows.
>

That's part of at least one of the proposals on deck.  But that same
proposal talks about adding to the signal available to the receiver, not
changing or removing it.


> I've been thinking some more about this and mentally I'm swinging back
> more
> towards the system is working as designed, don't mess with it.
>
> If an ESP is willing to take on a trial customer they know nothing about
> and
> let them send email leveraging the reputation of the ESP's domain, why is
> it
> wrong that it suffers when that does not end well.
>

It's not always a commercial ESP.  The identified attack works today if you
are a private user using a public mailbox service provider.


> I've yet to see any proposed problem that can be resolved without
> disrupting
> legitimate mail flows or standing the 5321/5322 architectural division on
> its
> head.  I know it when I see it isn't a sufficient definition.
>

Repeating what I said above, I think there are some ideas on the table that
seek to provide incremental information for receivers to use in these
cases.  The disruption should be minimal, unless the receivers broadly get
it wrong.


> I can imagine the market solving this.  If there are two ESPs and one is
> careful about who is allowed to send mail signed by their domain and the
> other
> is not, I suspect that eventually superior reputation will result in
> superior
> deliverability, which should result in being able to charge more for a
> premium
> service.
>

I think that clearly this approach could work.  It's not a massive leap to
conclude that senders shouldn't sign spam, but it's also well established
that spam filters are not perfect.  All an attacker needs to do is identify
some pattern the filters don't detect, and get that signed, and this attack
works despite the best efforts of the sender.

More concerning to me: The IETF has previously taken the position that the
market will figure out spam and phishing, and therefore consideration of
protocol solutions should be deflected.  DMARC was the result.   I feel
that we leave this to the market, and that industry, at our own peril.  I
think we should give this a serious look before rejecting it outright.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Thu, Nov 10, 2022 at 1:24 PM Murray S. Kucherawy 
wrote:

> [offlist]
>
> ...
>

Actually I didn't intend for it to be offlist, sorry for the confusing tag.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

[offlist]

On Thu, Nov 10, 2022 at 1:21 PM Laura Atkins 
wrote:

>
> On 10 Nov 2022, at 13:17, Murray S. Kucherawy  wrote:
>
> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins 
> wrote:
>
>> In many cases, the reason the mail isn’t going out through the signing
>> domain is because the signing domain’s anti-spam heuristics are good enough
>> that the sender couldn’t maintain an account there long enough to send out
>> any volume of email. That’s why the domain has a good reputation - because
>> they block spam off their network. This is a way to steal the good
>> reputation from the good ESP.
>>
>
> Interesting.  Almost seems like "SPF against the signing domain" could be
> a win, except for all the usual forwarding concerns.
>
>
> I think a lot of it is being blocked and the receiving orgs are aware it’s
> happening and the replays are not contributing that much to the actual
> reputation of the originating domain. Certainly, what I’m hearing from the
> folks who are being used as the signer for the replay is they’re not seeing
> a whole lot of impact on delivery and reputation.
>

Am I reading this right, i.e., you think this is mostly a non-issue because
it's easy to spot and filter?

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins 
wrote:

> In many cases, the reason the mail isn’t going out through the signing
> domain is because the signing domain’s anti-spam heuristics are good enough
> that the sender couldn’t maintain an account there long enough to send out
> any volume of email. That’s why the domain has a good reputation - because
> they block spam off their network. This is a way to steal the good
> reputation from the good ESP.
>

Interesting.  Almost seems like "SPF against the signing domain" could be a
win, except for all the usual forwarding concerns.

2) The messages often have two different To: lines
>

This violates RFC 5322, so it would be easy to filter these out, except
that we would need to know how common and tolerated this is today among
legitimate messages.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman 
wrote:

> I agree that we don't want too much detail in the charter about the
> technical
> nature of the problem, but I would like to understand it in more detail in
> order to better assess the appropriateness of what is there.
>
> If a domain is signing spam and their reputation suffers as a result,
> isn't
> that the system working as designed?
>

For cases of very large operators, like Gmail, their reputation doesn't
suffer to the extent that their mail becomes untrusted.  The abuser thus
has a very long runway before something like that could start to happen.


> I would like to understand what is the technical characteristic of these
> messages that is distinct from the non-bad ones.  As far as I can tell
> (and
> this isn't the first time I've run across these discussions), there isn't
> one.
> If that's the case, then I don't think there's an actual technical
> solution to
> this problem.
>

It may or may not be possible to reduce it to a technical characteristic.
However, the attack amounts to a Trojan horse whose distribution is enabled
or increased by DKIM; who's to say malware can't be sent this way?  In my
view, that makes it something worth attention.

Once work is chartered in the IETF, it tends to get a certain momentum
> toward
> producing a result.  Before agreeing that we have a charter to solve a
> problem, I'd like to understand we have a problem that can be solved, even
> though that requires a bit of discussion at a more detailed level than
> what
> eventually goes in the charter.
>

I think of the charter as the contract between the working group and the
IESG that constrains what it will produce.  The questions you're asking
here tend to be the things we ask in the discussion around the charter,
particularly during a BoF session to discuss working group formation, but
not necessarily what goes in the charter directly.

So I think your question is a legitimate one, but I'm not sure what text
the charter ought to contain in order to address it directly.


> Leaving aside algorithms and processes for a moment, could someone
> describe
> how an technically proficient human would examine one of these messages
> and
> determine they are "bad"?
>

The message itself is usually indistinguishable between its first instance
(when it's signed) and its second (when it's replayed).  The envelope,
however, has to vary; that's a key property of the attack.  One possible
solution is to come up with a scheme that factors that part of the envelope
into DKIM's operation; another is to pack useful metadata into the message,
independent of DKIM, so a downstream receiver stands a chance of telling
the difference between a first instance and a replayed instance.  Which of
those two approaches should be used, and the exact mechanism of doing so,
would be the output(s) of this working group.

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

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

[Murray S. Kucherawy]

On Tue, May 12, 2020 at 11:14 AM Alessandro Vesely  wrote:

> On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote:
> > On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely 
> wrote:
> >> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> >>> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely 
> wrote:
> >>>> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> >>>>> Indeed; why would I believe what any given domain claims in this tag?
> >>>>
> >>>> If you trust the domain, you can as well trust their tagging.
> >>>>
> >>>
> >>> If you trust the domain, you don't need their tagging.
> >>
> >> Why not?  I may trust gmail, say.  Yet, in order to learn what
> >> restrictions they apply to the From: I have to create an account and
> try.
> >> There is no standard location where they declare their policy in a
> >> machine-readable manner, and policies written in legalese are even less
> >> readable...>>
> >
> > What would you do with that information if you had it?
>
> I think I'd copy it to comments in the corresponding A-R header field.
> That
> would make A-R stanzas more eloquent.
>

So this is ultimately for human consumption?  Now I'm really confused.

> Maybe you're using a different definition of "trust" than I am.  To me, "I
> > trust gmail.com" means "I believe mail signed by gmail.com is
> legitimate",
> > irrespective of how they might handle their mail.
> >
> > Put another way: I believe I would only reach the opinion that I "trust"
> > mail from a domain when I already know the thing(s) your tag(s) would
> tell
> > me.
>
> "Trust" and "legitimacy" are abstract terms deeply rooted in human senses,
> i.e.
> hardly machine readable.  For a more pragmatic definition of trust, "I
> trust
> gmail.com" would mean "I believe that header fields written by gmail.com
> are
> true to life (up to transient bugs)".  In that sense, if they stated that
> the
> From: corresponds to the login Id, I'd believe it.
>

I think you're agreeing with me, or I'm failing to see the difference.

If you believe that header fields written by gmail.com are true to life,
what more can these tags tell you?


> Hey, what if gmail used different selectors for newcomers?
>

What would you do with that information?  Or given your answer above, what
would one of your users do with that information?

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

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

[Murray S. Kucherawy]

On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely  wrote:

> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> > On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely 
> wrote:
> >> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> >>> Indeed; why would I believe what any given domain claims in this tag?
> >>
> >> If you trust the domain, you can as well trust their tagging.
> >>
> >
> > If you trust the domain, you don't need their tagging.
>
> Why not?  I may trust gmail, say.  Yet, in order to learn what restrictions
> they apply to the From: I have to create an account and try.  There is no
> standard location where they declare their policy in a machine-readable
> manner,
> and policies written in legalese are even less readable...
>

What would you do with that information if you had it?

Maybe you're using a different definition of "trust" than I am.  To me, "I
trust gmail.com" means "I believe mail signed by gmail.com is legitimate",
irrespective of how they might handle their mail.

Put another way: I believe I would only reach the opinion that I "trust"
mail from a domain when I already know the thing(s) your tag(s) would tell
me.

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

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

[Murray S. Kucherawy]

On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely  wrote:

> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> > Indeed; why would I believe what any given domain claims in this tag?
>
> If you trust the domain, you can as well trust their tagging.
>

If you trust the domain, you don't need their tagging.

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

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

[Murray S. Kucherawy]

On Mon, May 11, 2020 at 10:30 AM Dave Crocker  wrote:

> On 5/11/2020 10:21 AM, Alessandro Vesely wrote:
> > The question is, what responsibility is being claimed?
> 
> > Tagging keys with aim= would allow senders to choose an appropriate
> selector
> > under different circumstances.
>
> If signers want to have a standardized means of indicating the
> fine-grained semantics behind their signature, they can do that without
> modifying DKIM.
>
> Rather, define and use a header field that specifies DKIM signing
> policy.  Cover it with the DKIM signature, of course.
>
> The only interesting part of this task is deciding on a standard set of
> policy labels.
>
> Oh, and then figuring out why and how they are useful to provide...
>

Indeed; why would I believe what any given domain claims in this tag?

If the response to that is that you will trust only what certain domains
say here, then you probably already know the equivalent of what's in the
tag anyway.

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

Re: [Ietf-dkim] Looking for a little help testing DKIM failure reports, thank you.

[Murray S. Kucherawy]

DKIM verifiers are not required to generate reports.  It's completely
optional.  Does the place you're sending to advertise somehow that they
will be generated?

On Mon, Dec 17, 2018 at 8:36 AM Fazzina, Angelo 
wrote:

> Hi, I am trying to test my TXT records for the ability to report failures..
> Talking about RFC 6651
>
>
>
> *These are my records*
>
>
>
> dkim1._domainkey.mta5.uits.uconn.edutext = "v=DKIM1\; k=rsa\;
> p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/YIuJIABa9M7Ox5AXs6CP6z26d/i9JDrHW58YU/OzfsEr6yADboIOydCaiiVaNuwtkbx
>
>
> catzd6/iutxWbAiY51rRAvVdBs2YIoGO6Glzeev66ft8IfMnHgxND438KIsdOjUmJZuglFJUWGzCYDSC1eq/zqDVncFwTxWkKW/qtxQIDAQAB"
>
>
>
> _report._domainkey.mta5.uits.uconn.edu  text = "ra=dkim-errors\; rp=100\;
> rr=all"
>
>
>
>
>
> *Here is a test email sig header*
>
> v=1; a=rsa-sha256; c=relaxed/simple; d=mta5.uits.uconn.edu; s=dkim1;
> t=1544820643; r=y; bh=9ZoLOUiYT9ubu7ykLiU305ZLqHeoTNV83po4QgGRepU=;
> h=To:From:Subject:Date:From;
> b=uPOMfVq7Ilr0/e2GEwEIiRotuX1gacod2Tmk7c1lfcYUpNTUznjUXPyNidTlbhrLA
> ylDHc1xE1P/B1NBo0awxBN4Qbwjz8UWUC1vQpQsrenWnhr+Rp46g7KKqWWZ2Sjw0O0
> 0RV2EF9aD1UP5bd7qLtuQHQ9gye5cVCBv6uVdM7g=
>
>
>
> *Here is a test email result header*
>
> spf=none (sender IP is 137.99.25.249) smtp.mailfrom=appmail.uconn.edu;
> uconn.mail.onmicrosoft.com; dkim=fail (invalid public key) header.d=
> mta5.uits.uconn.edu;uconn.mail.onmicrosoft.com; dmarc=none action=none
> header.from=appmail.uconn.edu;compauth=pass reason=105
>
>
>
>
>
> So I can simulate a failure, but cannot seem to get a report emailed to
> dkim-err...@mta5.uits.uconn.edu ?
>
>
>
> *I made sure account exists on server:*
>
> [root@mta5 home]# ls -l /home/|grep dkim
>
> drwx--. 2 dkim-errors   dkim-errors 78 Dec 10 16:21
> dkim-errors
>
>
>
>
>
>
>
> How often are the failure reports generated ? did not see that mentioned
> in the RFC’s ?
>
>
>
> Does anyone see anything obvious that I am doing wrong ?
>
> Thank you.
>
>
>
>
>
> -ANGELO FAZZINA
>
>
>
> *ITS Service Manager:*
>
> Spam and Virus Prevention
>
> Mass Mailing
>
> G Suite/Gmail
>
>
>
> ang...@uconn.edu
>
> University of Connecticut,  ITS, SSG, Server Systems
>
> 860-486-9075
>
>
> ___
> 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-Signature: r=y and MLM

[Murray S. Kucherawy]

On Sat, Aug 18, 2018 at 10:42 PM, Dilyan Palauzov  wrote:

> I suggested to write in ARC to alter the existing signature.
>

As I said before, I suspect you will have a hard time selling an "alter the
existing signature" idea no matter what document you propose to create or
update.

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

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

[Murray S. Kucherawy]

On Sat, Aug 18, 2018 at 8:30 PM, Dilyan Palauzov 
wrote:

> Two out of two responders were against removing r=y from the
> DKIM-Signature.
>
> I am fine with removing the invalidated DKIM-Signatures, but mailman
> developers are not (https://gitlab.com/mailman/mailman/issues/500) as
> this were incompable with ARC.
>
> What about writing in ARC, which I have not read, to remove r=y, before
> handling DKIM-Signature:s?
>

Do you mean for ARC to ignore "r=y"?

Otherwise, isn't this again altering an existing signature, which consensus
(so far) disagrees with?

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

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

[Murray S. Kucherawy]

On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov 
wrote:

> I suggest here in to suggest in a more formal manner, that MLMs modifying
> a message are supposed to remove the r=y part of just invalidated
> DKIM-Signature and this logic is also applied for ARC, if relevant (I don't
> know ARC).  Fixing only ARC will not help, as there is software that
> follows DKIM, but has no idea about ARC.
>
> Is such a recommendation a good idea?
>
> How to make the recomentation?  Amendment to RFC6377, amendment to RFC
> 6651, something else, that is very short to compose?
>

I think advising anyone to alter a signature on a message irrespective of
the signature's validity will be hard to sell.  It would be simpler to just
remove the signature entirely if there's a good reason not to want it there
anymore.

This unfortunately seems a rather small thing for which to spin up an
update to either RFC6377 or RFC6651.  Are there any other things that have
evolved since those documents were published that might make revisions
worth doing?

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

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

[Murray S. Kucherawy]

On Sat, Aug 18, 2018 at 2:45 PM, Murray S. Kucherawy 
wrote:

> On Fri, Aug 17, 2018 at 4:15 AM, Alessandro Vesely  wrote:
>
>> > The DKIM aggregate reports show whether a server signs correctly all
>> mails or
>> > not.  If the aggregate reports show that this is sometimes (let's say
>> in 1%)
>> > not done correctly, the signer has no way to find for which email the
>> signing
>> > has not worked and cannot fix the signing software, unless a report for
>> the
>> > failing mail is sent with r=y.
>>
>> Well, nope.  Aggregate reports belong to DMARC.  Consider adding a rua=
>> address
>> to your DMARC record.  Sometimes aggregate reports allow a postmaster to
>> pin
>> which message triggered it.  If you also set a ruf= address, you might
>> receive
>> ARF reports as well.
>>
>
> +1.
>

Actually, Dilyan is correct; RFC6651 introduced a reporting stream
independent of DMARC.  I've no data about how widely it's used outside of
OpenDKIM, however, but it's not strictly a DMARC or ARC mechanism.

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

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

[Murray S. Kucherawy]

On Fri, Aug 17, 2018 at 4:15 AM, Alessandro Vesely  wrote:

> > The DKIM aggregate reports show whether a server signs correctly all
> mails or
> > not.  If the aggregate reports show that this is sometimes (let's say in
> 1%)
> > not done correctly, the signer has no way to find for which email the
> signing
> > has not worked and cannot fix the signing software, unless a report for
> the
> > failing mail is sent with r=y.
>
> Well, nope.  Aggregate reports belong to DMARC.  Consider adding a rua=
> address
> to your DMARC record.  Sometimes aggregate reports allow a postmaster to
> pin
> which message triggered it.  If you also set a ruf= address, you might
> receive
> ARF reports as well.
>

+1.

> I suggest here in to suggest in a more formal manner, that MLMs modifying
> a
> > message are supposed to remove the r=y part of just invalidated
> DKIM-Signature
> > and this logic is also applied for ARC, if relevant (I don't know ARC).
> Fixing
> > only ARC will not help, as there is software that follows DKIM, but has
> no idea
> > about ARC.
>
> AFAIK, ARC is not involved in reporting.  My feeling is that the whole
> topic
> now belongs to DMARC's territory.


+1.

As for rfc6651, it also specifies how to obtain reports for ADSP, which was
> moved to Historical status.  Unless your experience testifies to a relevant
> community traction, I'd propose rfc6651 be moved to Historical status too,
> and
> its format description be moved to rfc7489bis, whenever it comes about.
>

OpenDKIM still implements RFC6651 and finds it useful for debugging
problems with new implementations, so at least from that perspective I
don't think historical status for it is warranted.  If an update is needed
to cover the issues raised here, that's possibly worth pursuing.

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