[Ietf-dkim] Re: Manipulation of signed messages

[Alessandro Vesely]

On Thu 30/May/2024 19:19:16 +0200 Murray S. Kucherawy wrote:

On Thu, May 30, 2024 at 9:13 AM Alessandro Vesely  wrote:

z= saves all fields, which would be too much in most cases.  Moreover, 
doing so suggests treating all fields as a whole, rather than dealing with 
each one's peculiarity. >

That's not what the RFC says.



Most implementations put there all signed fields.  OpenDKIM also "skip" fields.

Undoing transformations is not a diagnostic operation.  For example, Mailman 3 
is qp-encoding the Subject:


X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: =?utf-8?q?=5BIetf-dkim=5D_Re=3A_Manipulation_of_signed_messages?=

That way I cannot verify Gmail's signatures any more.  Diagnostics is only 
needed to get the culprit, so as to better the heuristics...



Of course, if an Original- field is tampered with the original signature 
won't verify after replacing it, just like if you altered z=.  But then, 
reverting without cooperation is not the same as doing it with active 
opposition. Why would someone alter Original- fields?  A mediator wanting 
to disrupt the possibility to reverse had better removing the signature 
directly. >
Space munging applied to all fields, for example, is enough to break this 
scheme.  "z=", by contrast, is immune to such mutations, because it's 
encoded.



Right.  However, Mailman re-folds header fields it writes from memory, so if 
canonicalization is not relaxed the verification fails anyway.  z= doesn't 
include itself.



Best
Ale
--





___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: Manipulation of signed messages

[Alessandro Vesely]

On Thu 30/May/2024 15:27:51 +0200 Murray S. Kucherawy wrote:

On Thu, May 30, 2024 at 3:30 AM Alessandro Vesely  wrote:


z= is a valuable tool for debugging and learning why signatures fail.
For reversing purposes, instead, Original-* fields are preferable as they 
can be individually added and possibly signed also by different 
operators. Reversal must not blindly replace altered fields so as to force 
verification.  It should check whether the applied changes meet per-field 
acceptance criteria. >
I don't understand your "preferable" claim given that an Original-* field 
is subject to mutation just as any other field is.  It's just as fragile as 
any other solution.  At least with "z=", you're far more likely to get back 
an actual original.



z= saves all fields, which would be too much in most cases.  Moreover, doing so 
suggests treating all fields as a whole, rather than dealing with each one's 
peculiarity.


Of course, if an Original- field is tampered with the original signature won't 
verify after replacing it, just like if you altered z=.  But then, reverting 
without cooperation is not the same as doing it with active opposition.  Why 
would someone alter Original- fields?  A mediator wanting to disrupt the 
possibility to reverse had better removing the signature directly.



Best
Ale
--




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: Manipulation of signed messages

[Alessandro Vesely]

On Thu 30/May/2024 00:02:40 +0200 Murray S. Kucherawy wrote:


"z=" has been around since RFC 4871.  The "z=" tag, when used, typically 
contains an encoding of the entire original header.  This could be used to 
recover a signature that was invalidated by a header field modification of some 
kind.  Has anyone heard of a verifier actually doing so?


OpenDKIM can do this.  It won't then switch the result to a valid one, but it 
will at least tell you what change was made to the header that invalidated the 
signature so you can pass that information back to the signer if you wish.  I 
thought this was a valuable thing to add at the time, but I don't think I've 
ever heard of anyone trying to extend it to change the validation result.



z= is a valuable tool for debugging and learning why signatures fail.  For 
reversing purposes, instead, Original-* fields are preferable as they can be 
individually added and possibly signed also by different operators.  Reversal 
must not blindly replace altered fields so as to force verification.  It should 
check whether the applied changes meet per-field acceptance criteria.


Likewise for identifying the footer.  To store the original body hash obviously 
is not an acceptable solution.



All of that is meant to say that the idea of undoing mutations you're able to 
identify has existed for a while, at least in one implementation.  However, 
since it hasn't been identified as an interesting capability in the intervening 
years, it would seem to support Barry's claim that a broken signature oughta 
just stay broken.



There is a set of gentle changes that we learned to accept and treasure during 
decades of mailing list usage.  However, that set, which we may call 
traditional, was never standardized.  In addition, there are other kinds of 
community-distributed messages that might also be called mailing list, even 
though they don't follow that tradition.  Thence some confusion.


Rather than not interesting, the reversing capability has been identified as 
fragile and messy.  Yet it is the only possible /unilateral/ remedy to From: 
munging, AFAICS.  The latter, in turn, is the preferred unilateral remedy to 
DMARC.  In this respect, it looks like we lost the ability to develop 
cooperative solutions.



Best
Ale
--




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: Manipulation of signed messages

[Alessandro Vesely]

On Wed 29/May/2024 19:29:27 +0200 John Levine wrote:

It appears that Alessandro Vesely   said:
My verifier, in particular, works every time on my messages.  It doesn't mean 
it doesn't work at scale.


Nor, of course, does it mean that it does.



Agreed.

However, if it doesn't work for a given list, it's always possible to add more 
stuff in the header that will help the verifier restore the original values and 
evaluate if the amount of change the list applied is acceptable.  Since the 
signer and the verifier is the same program, it's easy to coordinate.



Best
Ale
--




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Wed 29/May/2024 19:22:54 +0200 John Levine wrote:

It appears that Alessandro Vesely   said:
I did try and use it.  You have to be careful to put the subject tag on new 
messages or write /Re:/ in the right place.  You must not sign MIME-Version: 
and other fields that the MLM writes anew (yes, also Content-Type:).  Oh, and 
never send multipart (HTML) messages.  With such limitations, l= does sometimes 
deliver enough robustness for a signature to survive through a MLM.  Unless the 
MLM transforms the whole stuff to base64, that is.


Or it changes the MIME boundary string, or it puts text at the front 
of the body, or it changes the subject or any of the other signed 
headers, or it does any of a hundred other things that lists do.



Yes, I didn't mean to be exhaustive.  I only recounted my experience when I did 
try it, on this list in 2011.



There are certainly some cases where a signature with l= will still be 
valid after the message goes through a list, but it's unpredictable 
and fragile so no sensible person would count on it.



That's more or less what I wrote.


Best
Ale
--



___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: Manipulation of signed messages

[Alessandro Vesely]

On Sat 25/May/2024 19:02:04 +0200 Dave Crocker wrote:


1) It appears that the issue with l= is that implementers are not doing 
it correctly, and that there's even lazy-unto-hostile use of it. If this 
  is the case, that implementers are not doing the spec properly, I don't 
  see that changing the spec is going to fix the issue, that of 
implementers not doing the spec.


There is a basic reality that this situation demonstrates and that we should 
learn from: interoperability at scale is difficult to achieve and maintain.  
And when something is fragile like this, we should be careful about expecting 
actions that mess with it to work reliably, at scale.


So, for example, the pleasant idea of being able to reverse manipulations done 
by mailing lists ought to give everyone very considerable pause.  We haven't 
done well with the first manipulation, so why should a second one do well?



If it doesn't, we can try with a third one.  Something ought to work.

My verifier, in particular, works every time on my messages.  It doesn't mean 
it doesn't work at scale.  It means every body can add enough robustness to 
their signatures for them to pass through MLM by undoing transformations.



Best
Ale
--




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Tue 28/May/2024 21:08:26 +0200 Hector Santos wrote:

On May 25, 2024, at 12:49 PM, John R Levine  wrote:
On Fri, 24 May 2024, Jon Callas wrote:

1) It appears that the issue with l= is that implementers are not doing it 
correctly, ...


If there ever was a correct way to use l=, there sure isn't now.  But per 
your next message we seem to agree on the outcome.


Yet, as shown, there are many implementations that support it for usage 
(outbound) and ignoring (inbound) per the consensus.   I did agree with the 
option and left it as option for sysops to enable/disable.   But I agree it was 
not an answer to restoring original verification and can be a loop hole.



I did try and use it.  You have to be careful to put the subject tag on new 
messages or write /Re:/ in the right place.  You must not sign MIME-Version: 
and other fields that the MLM writes anew (yes, also Content-Type:).  Oh, and 
never send multipart (HTML) messages.  With such limitations, l= does sometimes 
deliver enough robustness for a signature to survive through a MLM.  Unless the 
MLM transforms the whole stuff to base64, that is.



Best
Ale
--



___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Thu 23/May/2024 20:13:07 +0200 John Levine wrote:

I guess this isn't as obvious as the authors of 6376 thought since we still
have at least one person on this list insisting that you don't need to sign C-T.



It's ill-conditioned to use l=.  Not signing C-T is fine.


Best
Ale
--




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Thu 23/May/2024 16:44:07 +0200 Wei Chuang wrote:

On Mon, May 20, 2024 at 7:17 PM Murray S. Kucherawy  wrote:

On Sun, May 19, 2024 at 9:27 AM Wei Chuang wrote:


[...]
One idea is to have the forwarder sign with an ARC Message-Signature and 
would take ownership of the new message. The forwarder would describe 
the offsets to recover the original body length and some receiver can 
validate the original DKIM signature.  Those offsets will also describe 
the forwarder's contribution to the message. There would also be 
problems around secure footer modification of Content-type header that 
are unsolved e.g. what to do if Content-type is oversigned.  All this 
work might be good candidates for the newly chartered Mailmaint WG. >>
Before we make suggestions about ARC, I would strongly suggest someone try 
that as a solution or mitigation to this problem.  I would not like us to 
publish something that shouts about this being a serious problem but then 
presents untested solution(s).  And frankly, I'd like to see ARC graduate 
out of Experimental status if that's what we want to put forward as a 
solution.


As to MAILMAINT as a venue, we'll have to see whether the community thinks
this is "big" or "small"; if the former, it should probably get its own WG.


Just specifically in regards authenticating mailing list modifications: 
fair enough that the ideas should be implemented first before any sort of 
IETF publication for it.  Still there ought to be a place for informal, 
early discussion of ideas on authenticating mailing lists.  For this 
proposal, I think there are issues around the intersection of DKIM signing 
and Content-type, and in particular, there will be advice such as in the 
researcher's blogpost 
 that 
calls for "h=" oversigning the Content-type header to help prevent the 
delimitter modification as was done.  While understandable, I suspect this 
prevents adding a mailing list footer as a new MIME part and perhaps too 
restrictive.  Instead would it be reasonable to say there be sufficient 
protection if the forwarder takes ownership of appended footers?  If not, 
another approach would be to version the Content-type header?  Yet another 
approach would be to resign the DKIM signature by the forwarder, but that 
hides who the sender is causing UI and spam filtering problems.



I agree that signing Content-Type: is overkill.


Going back to my original point, would the ietf-dkim list be the right place 
for this cross-cutting discussion?  I think there are a few targeted 
questions that need some discussion.  (We're interested prototyping but 
that's at least a quarter or so away)


I think mailmaint can be a good venue for airing these kind of proposals, 
without committing the WG to an extensive discussion, that is without I-D 
adoption.  Or is it better ietf-dkim?  Or ietf-smtp?



Best
Ale
--








___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Tue 21/May/2024 16:41:20 +0200 John Levine wrote:

It appears that Alessandro Vesely   said:

I'd be curious to learn why [John would certainly want the signature to 
break if someone changed the Content-Type header on a message he sent].  A 
mailing list might change it from >>

   Content-type: text/plain; charset=utf-8
to
   Content-Type: text/plain; charset="utf-8"


I have trouble imagining that many mailing lists would make that 
change and only that change and would otherwise leave the message 
untouched.



The other change they did, footer addition, can be easily undone.  Guessing 
whether the original C-T had quotes rather than us-ascii or what else would 
require several attempts, which makes it not worth.



In any event, as we've now said several times, the Content-Type attack 
is specifically described in RFC 6376.  I see that the perl and python 
DKIM modules sign the content-* headers by default.



That attack only works if there is l=, AFAIK.

I've seen several blogs recommending to sign "technical" fields like 
Content-Type, Content-Transfer-Encoding and even MIME-Version.  I really don't 
think this message would take on a different meaning if someone changed that to 
be, say, MIME-Version: 1.5.



Best
Ale
--



___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Mon 20/May/2024 20:10:44 +0200 John Levine wrote:

It appears that Jeremy Harris   said:

On 20/05/2024 09:06, Alessandro Vesely wrote:

Content-Type: is a technical field


Not a term I've met before.  Is there a formal definition?


As Dave said, no.  There isn't even an informal definition.



Informally, I think it's quite straightforward to distinguish between technical 
versus semantic fields.



And as far as "which forwarders need to change" goes - 
isn't the entire point of DKIM to detect chages?


If someone changed the Content-Type header on a message I sent, 
I would certainly want the signature to break.



I'd be curious to learn why.  A mailing list might change it from

   Content-type: text/plain; charset=utf-8

to

   Content-Type: text/plain; charset="utf-8"

which makes the signature unrecoverable, as in the case of the message I'm 
replying to.  Or they may want to wrap the message into a multipart with a 
footer.  For consistency, they set that field to the correct value which 
describes the structure of the message they distribute.  Why would that change 
matter when the semantic part of the message is unaltered?



Best
Ale
--




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Sun 19/May/2024 21:28:21 +0200 Jeremy Harris wrote:

On 19/05/2024 17:26, Wei Chuang wrote:

then rewrite the Content-type header mime delimiter


Seems like including this header in the signed set would be 
Best Practice?



I hope not.  Content-Type: is a technical field, which forwarders need to 
change, for consistency, if they apply even slightly changes to the body. 
Signing it hinders the possibility to verify the signature after heuristically 
removing the footer.


What should be Best Practice is not using l=.


Best
Ale
--



___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Alessandro Vesely]

On 05/02/2024 17:02, Hector Santos wrote:

On Feb 3, 2024, at 8:23 AM, Alessandro Vesely  wrote:

RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:, 
Resent-From:, Resent-To:, Resent-Cc: and Resent-Bcc:.


My comment was regarding the MUA and the order data is read. I wonder 
which MUAs will display a list for Display fields From: and Resent-*. If 
any.  Are all of these OverSign targets?



Resent-* fields can be added multiple times, so they should not be 
[over]signed.



if we go down this road, the recommendation might be to always sign all 
headers, including the missing, including ARC and trace headers and 
before signing, reorder specific headers to DKIM-ready MUA read-order 
standards, if any.



Trace fields, signatures and all "transit" stuff should neither be 
signed nor oversigned.



Are MUAs now doing verifications and filtering failures?  Or is it the 
backend, the host, the MDA, that is still generally responsible for 
doing the verification and mail filtering before passing it on to users?



It is debatable whether it is useful to display authentication 
information to the end user.  Personally, I like to see it.


MUAs which have add-ons probably have one or more DKIM verifiers.  Some 
implement it natively.



Best
Ale
--







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

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Alessandro Vesely]

On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote:
Of course, the MUA is another issue.  What read order should be expected for 
Oversign headers?  Each MUA can be different although I would think streamed in 
data are naturally read sequentially and the first display headers found are 
used in the UI.



Yeah, which is the opposite of DKIM specified order.



  Only To: is allowed to be a list.



RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:, Resent-From:, 
Resent-To:, Resent-Cc: and Resent-Bcc:.



Best
Ale
--






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

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Alessandro Vesely]

On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote:

If I add this feature to wcDKIM, it can be introduced as:

[X] Enable DKIM Replay Protection



That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while 
there can be other effects on signature robustness.  A better sentence could be:


[X] Prevent further additions of this field

Note that some packages allow choices such as

[ ] Sign and oversign only if present in the message
[ ] Oversign only if already present in the h= list
[ ] Oversign anyway


Best
Ale
--




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

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Alessandro Vesely]

On 16/01/2024 17:52, Mike Hillyer wrote:


One example of this documented is Brian Godiksen's blog post at 
https://www.socketlabs.com/blog/dkim-replay-attacks-preventive-measures-to-protect-email-deliverability


The post explicitly mentions subject, to, from, date and reply-to 
headers.  I don't know if signing technical headers (e.g. MIMI-Version) 
can help against replay, but it weakens signature's resilience.


The post says "One interesting aspect to these attacks is that messages 
are commonly modified by the attacker."  I guess they try and escape 
ESP's content filtering on outgoing messages...



Best
Ale
--



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

Re: [Ietf-dkim] DKIM Signature

[Alessandro Vesely]

On Mon 30/Oct/2023 20:44:20 +0100 Steffen Nurpmeso wrote:
I still think ED25519 is not gracefully supported by all DKIM implementations 
because you cannot use a stream based approach, but must load the entire data 
"in memory", it is a one-off algorithm.



Irrespective of what the advantage of simultaneous access the entire data would 
be, DKIM standardization of ed25519 keeps the same SHA256 hashing algorithms 
already used for RSA.  It signs the hash as if it were the whole data.

Neither I am a cryptographer.  Does this usage break collision resistance 
properties of Schnorr signatures?  I asked on stackexchange[*] but got no reply.


Best
Ale
--

[*] 
https://crypto.stackexchange.com/questions/108206/curious-behavior-of-evp-digestsign-for-dkim


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

Re: [Ietf-dkim] DKIM-FBL

[Alessandro Vesely]

On 9/27/23 16:47, Brotman, Alex wrote:

Some senders use a different selector when sending from different ESPs while 
they use the same d= in the DKIM signature.


Don't same d= mean they don't want to differentiate?  Using a different 
selector is an a artifact of keys distribution; it doesn't really 
substantiate a will to keep settings apart.



Best
Ale
--



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

Re: [Ietf-dkim] DKIM-FBL

[Alessandro Vesely]

On 9/27/23 13:36, Brotman, Alex wrote:
I've attached a draft that uses attributes of a passing DKIM 
signature to create a DNS label that can be used to discover an FBL 
address.  This feedback address can be used by message receivers to 
provide a copy of FN (and potentially FP) (Spam/Not-Spam) reports to 
the DKIM signers.  This allows for entities to perhaps sign with more 
than one signature, and provide feedback to each signer if desired 
(or each can list multiple rcpts if desired).  With traditional FBLs, 
the lookup is likely based off the final sender IP address, which 
could be the original sender, or an intermediary.  This DKIM-based 
method could aid both MBPs and ESPs in fighting outbound abuse from 
their platforms.  There are also methods in the document to attempt 
to do more to make reports smaller, aiding storage and PII concerns. 
Thanks for your time and feedback.


I'm not clear why would DKIM selectors (s=) be involved in the DNS name 
generation.  There are people who change selector for each message.  In 
general, selectors play no role in identification and are solely used 
for key rotation.  I guess your spec derives from seeing per-campaign 
selectors, but I doubt it is a common habit.  I'd suggest using 
subdomains for such purpose.



For a nit, consider the term "reporter" in the last paragraph of the 
introduction:


   By allowing reporters to discover the destination on their own, this
   should make getting FBLs to the original DKIM signer(s) easier.

As you hold that FBLs are reports from users to their MBPs, which only 
in some situations are forwarded to the original sender, the term may 
sound ambiguous.  I'd suggest "reporting MBPs" instead.



For discussion, it'd be interesting to analyze similarity and 
differences with List-Unsubscribe:, for FNs.  How would a MBP decide 
whether to make use of one, the other, or both methods to signal its 
user's reaction?



Best
Ale
--





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

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

[Alessandro Vesely]

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


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



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


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


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



Best
Ale
--




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

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

[Alessandro Vesely]

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

On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote:

On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson  wrote:__

Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in 
control of the signer, as opposed to the attacker.


Has anyone (else) implemented it?


That's what I want to understand. Or, more specifically, if no one implemented 
it, why? And have those blockers changed due to the changed landscape with dkim 
replay, etc.


When DKIM was young, a mechanism like the one defined in RFC 6651 was enormously valuable to me when two implementations were trying to debug interoperability problems.  It allowed us to see why signatures were failing. 
Once all the bugs were worked out and things like canonicalization and common MTA mutations were well understood, the need for this sort of thing faded away.


DKIM Replay is leading to interoperability problems as result of local policies 
being rolled out to mitigate the abuse, and senders (and their customers) need 
to make changes to their configuration to not get caught up in the emerging 
algorithms. Examples may include duplicate message throttling, blind recipient 
limitations, tighter expiration enforcement, etc.

I think usage of the 'p' and 'x' reports and the 'rs' tag would be valuable 
(perhaps enormously, as you experienced first hand)

pReports are requested for signatures that are rejected for local
 policy reasons at the Verifier that are related to DKIM
 signature evaluation.

xReports are requested for signatures rejected by the Verifier
 because the expiration time has passed.



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



Best
Ale
--








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

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Alessandro Vesely]

On Wed 30/Aug/2023 14:14:41 +0200 Dave Crocker wrote:

On 8/30/2023 1:21 AM, Alessandro Vesely wrote:

On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:

On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker  wrote:

On 8/29/2023 7:46 PM, Grant Taylor wrote:

On 8/29/23 9:02 PM, Dave Crocker wrote:

Why not re-use the existing DKIM solution, just with a different domain / 
set of keys?


Because it does not provide the affirmative information that I am 
postulating/guessing the originating platform can supply.


I have to agree.  It's compelling to consider that a high-trust domain might 
flag something for my extra consideration.  This could be done per-message, 
rather than per-key, which was Grant's counterproposal; the equivalent is to 
generate a selector per message, which appears at least on the surface to 
suffer problems of scale.



The affirmative information can be provided by using semantic subdomain 
names, whose purpose and meaning has been registered. See the strawman here:

https://mailarchive.ietf.org/arch/msg/ietf-dkim/ez0PYqMdCDoR4-sN2toPGObMMFI


Except that there are no semantics to the domain naming components in DKIM, 
beyond the ones already defined.



That was defined in the strawman linked above, from last Friday.  Please have a 
look at it.



Best
Ale
--



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

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Alessandro Vesely]

On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote:

On 30 Aug 2023, at 03:38, Grant Taylor 
 wrote:
On 8/29/23 3:15 PM, Steve Atkins wrote:

Any attempt by senders to filter outbound emails based solely on content is 
going to have a lot of false negatives and positives, wherever you decide to 
draw the line.


I find the idea of using different, probably less stringent, filtering on 
outbound than on inbound to be hypocritical.


You have much more data for inbound email, and access to a much wider range of 
reactions. That’s not “hypocritical”.

The only information a sender has that a receiver doesn’t is a broader view of 
who the recipients of messages being sent are - and that’s exactly the 
information that DKIM replay hides from the sender.



Large sites should exchange reputation information on each other's accounts. 
Murray already proposed a standard for doing so.


Best
Ale
--





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

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Alessandro Vesely]

On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:

On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker  wrote:

On 8/29/2023 7:46 PM, Grant Taylor wrote:

On 8/29/23 9:02 PM, Dave Crocker wrote:

Why not re-use the existing DKIM solution, just with a different 
domain / set of keys?


Because it does not provide the affirmative information that I am 
postulating/guessing the originating platform can supply.


I have to agree.  It's compelling to consider that a high-trust domain 
might flag something for my extra consideration.  This could be done 
per-message, rather than per-key, which was Grant's counterproposal; the 
equivalent is to generate a selector per message, which appears at least on 
the surface to suffer problems of scale.



The affirmative information can be provided by using semantic subdomain names, 
whose purpose and meaning has been registered.  See the strawman here:

https://mailarchive.ietf.org/arch/msg/ietf-dkim/ez0PYqMdCDoR4-sN2toPGObMMFI


Rather than doing it in a header field, though, could it be done simply 
with a new tag?



The advantage of a subdomain w.r.t. a tag is that many receivers can operate on 
it natively, assigning reputation as normal, like Grant said, whereas a new tag 
would be ignored.



Let a domain establish a bad reputation.  Especially if it's being 
used for sending messages that are considered to be questionable.


Establishing a reputation takes time.  The likely behavior of a bad 
actor is within a very short time-frame.


And it is a single account, not the entire domain, that is the problem.


Or even a single message.



Or the ellipsis in Dave's "deemed spammy by the originating platform, or for 
new users who do not yet have an established quality record, or..."



And I've never understood why people get enamored of the idea of relying on 
bad reputations to spot bad actors.  A bad actor who thinks it has 
attracted a negative reputation need only move to a new name in an 
otherwise gigantic public namespace (domain name or IP address) to start 
over from zero.



I reject messages from domains newer than 30 days.  What is the time frame 
everybody else uses?



Best
Ale
--




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

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Fri 18/Aug/2023 12:21:31 +0200 Emanuel Schorsch wrote:


For example, we have seen very large DKIM Replay attacks of youtube.com 
Terms of Service emails. There is no malicious content in these emails, 
but spammers still send very large volumes (perhaps using them to 
generate affinity with victims or warm up their sending 
infrastructure). >>

That points to a bug in the I-D.  Section 3.1 says:

 A spammer will find a mailbox provider with a high reputation and that
 signs their message with DKIM. The spammer sends a message with spam
 content from there to a mailbox the spammer controls.

Youtube.com Terms of Service emails don't seem to have been sent by the 
spammer.


I agree, for completeness we should update that section to include both 
types of DKIM replay. I can work on sending a tweak to that section.



Please do!  Without it, Section 5.3, "Strip DKIM signatures on mailbox 
delivery" makes little sense.



But, to be clear this type of replay is definitely much less common than 
the spammer generated content. I just wanted to provide that it does also  
happen.


If there is a large difference, then the idea of segmenting authentication 
domains might actually belong to countering replay attacks, for spammers 
looking for high reputation signatures.  Some time ago I proposed 
d=bullshit.example.com, but after thinking a bit more, the I-D could set up a 
register for that.


For a strawman:

  5.6. Use segmented signature domains

 Domains that host mailboxes for widely different categories of users,
 typically free-mail domains, can differentiate the signature they affix
 on messages by using subdomains.  IANA maintains a register of subdomains
 used for this purpose (See Section 7.)

 *  Messages written by spammers who get categorized as such will be
signed by subdomains with low reputation, which lowers the incentive
to obtain the very signature.

 *  Careful users, who don't spam and don't have their accounts often
compromised, can use domains whose reputation won't be ruined by
replay attacks.

And

  7. IANA Consideration

 This document proposes the use of subdomain to categorize email message
 categories for which IANA is to create and maintain a new registry
 entitled "DKIM Semantic Subdomain Names".

 New registrations are published in accordance with the "First Come First
 Served" guidelines as described in [RFC8126].  They are to contain the
 following information:

 1.  Subdomain name to be used in the category.  The name MUST exist as a
 direct subdomain for the domain referred by the proponent, and MUST
 contain a non-empty _domainkey subdomain at the time or registration.

 2.  Short description of the category, and criteria for assigning messages
 to this category, possibly containing a link to extended description.

 3.  Trust that recipients are invited to assign to messages signed by such
 subdomain.  This MUST be one of the key words "none", "low", "medium"
 and "high".

 4.  Date of the registration.

 Note: Domains are invited to re-use existing names rather than registering
 new ones, if the intent matches the description.  These names are not
 visible by users, so there is no reason to use IDNs.  Names and
 descriptions MUST be in English.


That's all folks
Ale
--






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

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Thu 17/Aug/2023 20:12:51 +0200 Emanuel Schorsch wrote:

On Thu, Aug 17, 2023 at 2:06 PM Alessandro Vesely mailto:ves...@tana.it>> wrote:


If corporate domains are victims of replay attacks at the same rate as
free mail providers, then my theory is wrong.  See below. >
  Ale, I think there is a lot of value in what you are saying about 
verification of identities and segmentation of the authenticating domain based 
on the tier of verification that was performed.



Thanks.


BUT, I think this is a good idea that is separate from DKIM Replay. 
Specifically, we do see non-free mail providers as victims of DKIM Replay as 
well.



If the rate is similar, I agree.  That kind of information is missing from the 
I-D.


For example, we have seen very large DKIM Replay attacks of youtube.com 
Terms of Service emails. There is no malicious content in these emails, but

spammers still send very large volumes (perhaps using them to generate
affinity with victims or warm up their sending infrastructure).


That points to a bug in the I-D.  Section 3.1 says:

A spammer will find a mailbox provider with a high reputation and that
signs their message with DKIM. The spammer sends a message with spam
content from there to a mailbox the spammer controls.

Youtube.com Terms of Service emails don't seem to have been sent by the spammer.


Best
Ale
--




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

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Thu 17/Aug/2023 18:21:35 +0200 Murray S. Kucherawy wrote:

On Thu, Aug 17, 2023 at 3:30 AM Alessandro Vesely  wrote:

I'm not convinced advice is necessary here.  Do you really need signs in 
banks that say "Don't put your signature on random financial documents"?  I 
have to believe that people understand what it means to sign something, and 
why they shouldn't do that.


Well, when banks don't do that, they're in bad faith.  Consider, for 
example, derivative financial contracts conceived so that nobody is able 
to read them —banks don't even try to print them.  Decadent practices. >

I don't know what you mean by "decadent", here or below.

I disagree about the "bad faith" claim.  I think everyone with their own 
agency understands what it means to affix their signature to something. 
It's on them to understand that fully, or assume the risks of not being 
diligent.



When a customer who is dedicating (part of) an afternoon to banking has to 
/fully understand/ a 600 page agreement, the only choice he has is to assume 
the risk and blindly trust the bank.  You may disagree that that is bad faith. 
It's the kind of thing I'd call decadent.



In the case of high volume operations like scanning email, the scale forces 
you to play the odds that your inbound filtering gets it right a high 
enough percentage of the time that you're able to cope somehow with the 
things that slip through.



Yeah, here too you are forced to take the risk.  Domains who trust their users 
have easier options.



Domains cannot "read" the messages they sign.  Some MPs may have wonderful 
anti-spam filters, but that's still not the same as reading and signing an 
agreement.  We need to dismantle the agreement metaphor a bit.


The logical extension of this line of thinking is that message 
authentication isn't meaningful.  Is that where you're going with this?



No, the opposite.  Message authentication allows a system to vet messages 
without understanding their content, if it trusts the authenticated entities.



On the other hand, there are domains which blindly sign anything their 
users write, enacting only minimal limits to prevent abuse in case of 
compromised credentials.  They can afford doing so because, for example, 
users are employees and are known in person.  Do such domains experience 
replay attacks? >

Likely.  So?



If corporate domains are victims of replay attacks at the same rate as free 
mail providers, then my theory is wrong.  See below.



What I'm trying to address is the relationship between users and mailbox 
providers.  Free MPs want anyone to be able to create a free account, and 
that was at the root of their success.  When domain authentication 
arrived, they considered that /all/ messages from their domain must be 
authenticated. DMARC reporting is specifically aimed at such goal.


For something that signs at a domain level, why is this something with 
which we should concern ourselves?



Domains sign messages so that receivers can be sure about the origin.  The 
reputation a domain earns is then related to the amount of spam.  Trusted 
users, such as employees using a corporate domain, don't spam.  Therefore, spam 
emitted by such domain is proportional to the likelihood that its accounts get 
compromised.  My theory is that free mail providers and ESPs offering free 
trials host bad users whose purpose is to spam, either through replay or other 
kind of attacks.  This would result an an increased amount of reply attacks at 
such domains.


That's what I gathered from the I-D and this list's posts.  I repeatedly asked 
to narrate some real cases, but didn't hear any.  So I may be wrong.



The arms race you refer is the result of indiscriminately accepting all 
users. A small percentage of them are bad actors, but cannot be 
identified because, in general, the real IDs of users is not ascertained. 
At what point does claiming responsibility for non-ascertained entities 
results in decadent practices? >

Again, I don't know what this means.



By decadent I mean a practice of signing while the value of verified signatures 
gradually declines.  Signing for any Tom, Dick and Harry becomes just noise.



There is no equivalence between authenticating subscribers and scanning 
what they write.  Both tasks need human intelligence, but the former 
doesn't have to be done on each message.  Scanning w/o intelligence is 
only heuristic and relies heavily on volume limits, which is where replay 
attacks get away with it. >
...and this is entirely an internal matter.  Are you arguing that this 
deserves protocol-level consideration?



If the above theory is correct, a "potential solution" could be added to the 
I-D with considerations about varying signature ranks for domains with mixed 
users types.



If you're going to assert that Gmail should authenticate their users before 
allowing them to send stuff that will be signed, then I'

Re: [Ietf-dkim] replay is a bogus concept

[Alessandro Vesely]

On Thu 17/Aug/2023 04:45:48 +0200 Bron Gondwana wrote:

On Tue, Aug 15, 2023, at 21:36, Alessandro Vesely wrote:

On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote:


We've love to not sign spam at all, but short of never allowing users to send email, it's 
not actually possible.  We're not trying to "accomodate sites that send spam", 
we're trying to minimise the blast damage of a message that a bad actor manages to get 
signed - because that reduces that value of getting such a message stamped with a 
signature, and that reduces the amount of spam.


Still, knowing that he's a bad actor, you could skip signing.  Are there so 
many new spammers every day?  Or, rather, there is a bunch of professional 
spammers who know how to hide?


The whole point is - you don't know that a stolen account is a bad actor before it starts sending 
messages, and the ability to tell that a single message is spam, when it's being sent to a single 
recipient - again, if you have a reliable definition I'd love to see it.  Even something like `please 
click https://site.com/;>here to update your bank details`, real 
organisations send real email like that to their customers.  You can't tell it's spam without context.



Right, say you have to endure a replay attack only when an account is stolen. 
Would that diminish total replay attacks?  I mean, how many replay attacks are 
instead committed using loosely verified accounts?


Assuming one can verify the real ID of each account, that is.  Whether that is 
feasible, expensive, convenient or ground-breaking is a different question.



The whole concept of domain authentication is questionable if domains have no 
idea who their users are.


At scale, there's always going to be a small percentage of bad users / hacked 
users on any system.  Hence trying to make domain authentication not so 
valuable that getting it on a message is super powerful.



What is the value of domain authentication?  And what should it be?

To answer, consider you bought goods or services for a large amount.  The 
invoice arrives by email specifying the exact amount and the bank account code. 
 The mail is DKIM-signed.  Up to what amount would you trust and pay without 
calling?



Best
Ale
--






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

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Wed 16/Aug/2023 20:19:44 +0200 Dave Crocker wrote:

On 8/16/2023 10:48 AM, Murray^W Ale wrote:
Yet, an open 
signer is for DKIM the equivalent of what an open relay is for SPF.


It is nothing of the sort.

Open relays perform a relaying function, which actively moves mail, where the 
abuse is a) obfuscation, and b) fan-out.



Yup, I meant just from an SPF point of view, without the SMTP part.


What you are calling open signer allows adding any domain's authenticated 
identity onto the message, which permits other sites to develop and evaluate 
the reputation of the mail stream that uses the identity.


The former is abuse.  The second is potentially useful.

Since you think otherwise, please explain.



Maybe, instead of an open relay, I should've considered a site publishing this:
"v=spf1 ip4:0.0.0.0/1 ip4:128.0.0.0/1 ip6:0::/1 ip6:8000::/1 +all"

So it doesn't perform the moving function.

Either produces a waste of authentication checks at receivers.  Everybody can 
get anything authenticated.  The reputation others can develop from that is 
white noise.  I don't think it's useful.



Best
Ale
--






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

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Wed 16/Aug/2023 19:48:30 +0200 Murray S. Kucherawy wrote:

On Wed, Aug 16, 2023 at 10:25 AM Alessandro Vesely  wrote:

On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote:

On 16 Aug 2023, at 12:59, Alessandro Vesely  wrote:

On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:

On 16 Aug 2023, at 09:57, Alessandro Vesely  wrote:
How about enacting common sense rules such as Never sign anything 
without reading the small print?  In the same way that users agree to any 
Terms & Conditions without reading, domains sign any mail their users send 
without knowing.  Decadent practices, aren't they?
Can you expand on this? I’m not sure I understand how reading the 
content will fix the problem. Spam is an issue of volume mostly.
Avoiding to /sign without knowing/ could perhaps partially solve the 
problem. Reading the content was just for comparison with signing 
agreements.

Without knowing what, though? I am just not understanding what

Sorry, I meant without knowing who is the author.

According to RFC 6373, "DKIM separates the question of the identity of
the Signer of the message from the purported author of the message."  Yet,
an open signer is for DKIM the equivalent of what an open relay is for
SPF. >
I'm not convinced advice is necessary here.  Do you really need signs in 
banks that say "Don't put your signature on random financial documents"?  I 
have to believe that people understand what it means to sign something, and 
why they shouldn't do that.



Well, when banks don't do that, they're in bad faith.  Consider, for example, 
derivative financial contracts conceived so that nobody is able to read them 
—banks don't even try to print them.  Decadent practices.



We're already saying that a valid DKIM signature means the signer takes 
"some" responsibility for the message.  Saying "Don't sign random things" 
seems redundant to me; it presumes the first sentence is somehow deficient 
or hard to understand.  Is that what you're claiming?



Domains cannot "read" the messages they sign.  Some MPs may have wonderful 
anti-spam filters, but that's still not the same as reading and signing an 
agreement.  We need to dismantle the agreement metaphor a bit.



If this reduces to "Don't sign spam," then I don't think we need to say 
that.  Wei or Emmanual can confirm to be sure, but I'm pretty certain 
Google doesn't sign absolutely anything, in the sense that if you connect 
to them, authenticate, and then start spraying spam, it's going to get 
detected and disallowed somehow.


The problem occurs when someone finds a way through the spam filters.  I 
worked for a spam filtering company for a few years, but it doesn't take 
such direct experience to realize that it's an arms race: Attackers are 
trying to figure out what won't get caught and then exploiting that until 
the service provider catches up; rinse, repeat.  That gap will always come 
and go, and to assert that the gap should never ever be there and the 
service provider should be ashamed of itself if it ever occurs seems 
unrealistic to me.



On the other hand, there are domains which blindly sign anything their users 
write, enacting only minimal limits to prevent abuse in case of compromised 
credentials.  They can afford doing so because, for example, users are 
employees and are known in person.  Do such domains experience replay attacks?


What I'm trying to address is the relationship between users and mailbox 
providers.  Free MPs want anyone to be able to create a free account, and that 
was at the root of their success.  When domain authentication arrived, they 
considered that /all/ messages from their domain must be authenticated.  DMARC 
reporting is specifically aimed at such goal.


But domain authentication was conceived as a coarse-grained form of 
authentication where the responsibility that a domain claims is meaningful as 
long as membership to that domain qualifies an author in some way.


The arms race you refer is the result of indiscriminately accepting all users. 
A small percentage of them are bad actors, but cannot be identified because, in 
general, the real IDs of users is not ascertained.  At what point does claiming 
responsibility for non-ascertained entities results in decadent practices?



To repeat my questions, then, would limiting (qualified) DKIM signatures to 
verified accounts diminish replay attacks by any amount?  Is this kind of 
solution acceptable?


Sure, you should only sign things if you have reason to believe the source 
and the content are such that you're willing to attach your good name to 
it.  Whether that's authentication of the submitter or scanning of the 
content, or both, or other checks, is entirely up to you.  But by saying 
"you take some responsibility" for messages, I think we're already saying 
that and don't need to repeat ourselves.



There is no equivalence between authenticating s

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote:

On 16 Aug 2023, at 12:59, Alessandro Vesely  wrote:
On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:

On 16 Aug 2023, at 09:57, Alessandro Vesely  wrote:
How about enacting common sense rules such as Never sign anything without reading 
the small print?  In the same way that users agree to any Terms & Conditions 
without reading, domains sign any mail their users send without knowing.  Decadent 
practices, aren't they?

Can you expand on this? I’m not sure I understand how reading the content will 
fix the problem. Spam is an issue of volume mostly.


Avoiding to /sign without knowing/ could perhaps partially solve the problem. 
Reading the content was just for comparison with signing agreements.


Without knowing what, though? I am just not understanding what



Sorry, I meant without knowing who is the author.

According to RFC 6373, "DKIM separates the question of the identity of the 
Signer of the message from the purported author of the message."  Yet, an open 
signer is for DKIM the equivalent of what an open relay is for SPF.




Does Google know the real ID of its users?  I'd guess in many cases they do; 
for example, Google does payments and bank stuff which do require real IDs (I 
pay, therefore I am).  Nevertheless, they sign all email messages with the same 
d=gmail.com, irrespective of user reputation.
I fully understand the right to anonymity.  I know it's in the First Amendment, 
in the US.  However, I figure users should trust their mailbox providers enough 
to disclose their real ID.  The minority of people who really need to care 
about that can always find a provider in countries where ISPs cannot be forced 
to disclosure, or suffer sending lower grade mail.
Would that be an acceptable kind of solution?

I’m not sure I understand how this is a solution. As Evan and Emanuel have both 
said the bad actors have access to many thousands of accounts that look like 
real accounts. In my own experience, they have access to validating credit 
cards which is one of the most common ways to validate a real identity online.


There is an ongoing effort to safeguard digital identities (and plaguing people 
with 2FAs).  Checking IDs must be possible, and should be done in a number of 
cases.  Perhaps free mailbox providers could contribute...?


But 2FAs isn’t a realID, it’s just 2FA.



True.  When I happen to need 2FA it is for sites who know my real ID.  Yet 2FA 
by itself doesn't bring that info.




Before digressing about methods, the question is whether limiting signing to 
known (good) users could mitigate the replay problem.  Suppose an ESP or MP 
only signs mail authored by people who subscribed more than one month ago, and 
whose ID was verified less than six months ago.  Would that diminish replay 
attacks by any amount?


Given what I know of how spammers work, one month and 6 months to warm an 
account is trivial and something that a lot of spammers already bake into their 
setup processes.



You know this subject better than I.  I just said 6 months after how orgs like 
PGP Global Directory and Let's Encrypt behave.  Let's not digress about methods 
for a moment.


In the UE there are electronic ID cards issued by governments.  In Italy, the 
government additionally established SPID[*] whereby private ID providers can 
grant access to various sites.  They are both grounded on credentials emitted 
after in person contact.  Banks don't use SPID, but AFAIK require in person 
contact in order to create accounts.


Then, obviously, any method to verify an ID has weak points and bad actors will 
always slip through the cracks.  However, with what percentage of success? 
Since we're interested in volumes, a relevant quote of success is enough.


Email addresses are already often used as digital IDs, and I'm sure MPs make 
considerable efforts to keep them safe.  Yet, that can be improved.  To wit, 
while I saw several times Google vans acquiring the reality of streets, I never 
saw a Google officer acquiring the reality of user IDs.  How do large MPs 
manage accounts?  Don't they categorize them with some sort of trust indicator, 
like, say, inactive accounts, personal accounts, amount of traffic, in/out 
ratio, percentage of bounces and the like?  The kind of solution I'm trying to 
propose is about why DKIM signatures don't vary according on such indicator —if 
it exists.


The digital environment which is emerging deserves valid IDs anyway.  For 
example, are we able to enter job positions or sign agreements online?  Such 
abilities can be easily seen as a must for economic boost.  So can we assume 
that it is possible to determine real IDs of email accounts with reasonable 
accuracy?


To repeat my questions, then, would limiting (qualified) DKIM signatures to 
verified accounts diminish replay attacks by any amount?  Is this kind of 
solution acceptable?



Best
Ale
--
[*] https://www.spid.gov.it/e

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:

On 16 Aug 2023, at 09:57, Alessandro Vesely  wrote:

How about enacting common sense rules such as Never sign anything without reading 
the small print?  In the same way that users agree to any Terms & Conditions 
without reading, domains sign any mail their users send without knowing.  Decadent 
practices, aren't they?


Can you expand on this? I’m not sure I understand how reading the content will 
fix the problem. Spam is an issue of volume mostly.



Avoiding to /sign without knowing/ could perhaps partially solve the problem. 
Reading the content was just for comparison with signing agreements.




Does Google know the real ID of its users?  I'd guess in many cases they do; 
for example, Google does payments and bank stuff which do require real IDs (I 
pay, therefore I am).  Nevertheless, they sign all email messages with the same 
d=gmail.com, irrespective of user reputation.

I fully understand the right to anonymity.  I know it's in the First Amendment, 
in the US.  However, I figure users should trust their mailbox providers enough 
to disclose their real ID.  The minority of people who really need to care 
about that can always find a provider in countries where ISPs cannot be forced 
to disclosure, or suffer sending lower grade mail.

Would that be an acceptable kind of solution?


I’m not sure I understand how this is a solution. As Evan and Emanuel have both 
said the bad actors have access to many thousands of accounts that look like 
real accounts. In my own experience, they have access to validating credit 
cards which is one of the most common ways to validate a real identity online.



There is an ongoing effort to safeguard digital identities (and plaguing people 
with 2FAs).  Checking IDs must be possible, and should be done in a number of 
cases.  Perhaps free mailbox providers could contribute...?


Before digressing about methods, the question is whether limiting signing to 
known (good) users could mitigate the replay problem.  Suppose an ESP or MP 
only signs mail authored by people who subscribed more than one month ago, and 
whose ID was verified less than six months ago.  Would that diminish replay 
attacks by any amount?



BTW, how many replay attacks does an average ESP or MP notice in one month?

Is it legal to mount replay attacks?

Was any user responsible for replay attacks ever identified and prosecuted?


Best
Ale
--






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

Re: [Ietf-dkim] Replay attack definition discussion

[Alessandro Vesely]

On Tue 15/Aug/2023 14:59:18 +0200 Laura Atkins wrote:

On 15 Aug 2023, at 12:36, Alessandro Vesely  wrote:
On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote:



"Problem solved." [...]



Hm..  More than defining the replay attack, we need to define what kind of 
solution is acceptable.  The Basic solution space the I-D proposes doesn't 
include limiting what messages are signed by a domain.




We've love to not sign spam at all, but short of never allowing users to send email, it's 
not actually possible.  We're not trying to "accomodate sites that send spam", 
we're trying to minimise the blast damage of a message that a bad actor manages to get 
signed - because that reduces that value of getting such a message stamped with a 
signature, and that reduces the amount of spam.


Still, knowing that he's a bad actor, you could skip signing.  Are there so 
many new spammers every day?  Or, rather, there is a bunch of professional 
spammers who know how to hide?


How do you know he’s a bad actor before he does a bad action? That’s the crux 
of the problem:



Very much agreed.



the bad actor looks very much like a not-bad actor. You can’t generally tell 
the difference between the two until after the bad action has happened. In 
fact, the bad actor is often going to try and look as much like a not-bad actor 
as possible. That doesn’t mean they can’t be tracked. They are, and many of 
them get shut down based on patterns and vetting and a lot of things.



Tracking and shooting down is good.  However, as you note, it is not enough.

How about enacting common sense rules such as Never sign anything without 
reading the small print?  In the same way that users agree to any Terms & 
Conditions without reading, domains sign any mail their users send without 
knowing.  Decadent practices, aren't they?


Does Google know the real ID of its users?  I'd guess in many cases they do; 
for example, Google does payments and bank stuff which do require real IDs (I 
pay, therefore I am).  Nevertheless, they sign all email messages with the same 
d=gmail.com, irrespective of user reputation.


I fully understand the right to anonymity.  I know it's in the First Amendment, 
in the US.  However, I figure users should trust their mailbox providers enough 
to disclose their real ID.  The minority of people who really need to care 
about that can always find a provider in countries where ISPs cannot be forced 
to disclosure, or suffer sending lower grade mail.


Would that be an acceptable kind of solution?



But the reality is: bad-actors are going to get through every process. If we 
could ID spammers up front and stop them from spamming we’d very likely have 
done it already. In this case, they’re using DKIM in a way that was foreseen by 
the original authors but not treated as something that needed to be addressed 
in the protocol.



Yes, replay was considered.  Indeed, most protocol-change ideas being proposed 
these days turn out to have been already drafted at the time.  Anyway, changing 
DKIM doesn't seem to be something that will have practical effects in the short 
and medium term.  Consider ed25519, which is so straightforward to implement.



Best
Ale
--







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

Re: [Ietf-dkim] replay is a bogus concept

[Alessandro Vesely]

On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote:

On Thu, Aug 3, 2023, at 15:50, Michael Thomas wrote:

Barry Leiba  Tue, 01 August 2023 18:40 UTC


I do think the background is important to publish separately for this
work, however easy the problem is to describe.


It's because "replay" is a bogus concept and was discussed and rejected long ago. There 
is no solution. "Replay" is just a normal consequence of the email architecture.
[...]

If you don't want a bad reputation for spam, don't sign spam.
[...]

There is far too much financial interest going on here at the expense of ordinary users of email and the profiteers in the industry and their consultants. Don't send 
spam. Spend your money figuring that out. Problem solved.


"Problem solved."

As someone who has, as a person running a service with a large number of 
customers who can send email, ...

If you can provide me an accurate definition of spam which is not recipient 
specific and is actionable, I'd love to see it.   Even if we could, 
theoretically, vet every single customer sufficiently to make sure they're all 
well behaved people who never send spam, the probability that we can also 
ensure that their accounts are never compromised, their devices are never 
compromised, such that they never send anything spammy.  It's quite 
intractable, broad dismissive claims notwithstanding.



I won't try a definition.  However, I think it's easier to try a definition of 
spammer.  Probably we can stand the crowd of unintentional spammers whose 
account or device was compromised, or who innocently tried to sell their goods. 
 The bulk of actual spam is apparently authored by people who knows what 
they're doing.  Take this as a definition.  Is it actionable?




We've love to not sign spam at all, but short of never allowing users to send email, it's 
not actually possible.  We're not trying to "accomodate sites that send spam", 
we're trying to minimise the blast damage of a message that a bad actor manages to get 
signed - because that reduces that value of getting such a message stamped with a 
signature, and that reduces the amount of spam.



Still, knowing that he's a bad actor, you could skip signing.  Are there so 
many new spammers every day?  Or, rather, there is a bunch of professional 
spammers who know how to hide?


The whole concept of domain authentication is questionable if domains have no 
idea who their users are.



Best
Ale
--






___
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 Sat 12/Aug/2023 21:52:13 +0200 Steffen Nurpmeso wrote:

Alessandro Vesely wrote in :

On Fri 11/Aug/2023 23:49:20 +0200 Steffen Nurpmeso wrote:

Alessandro Vesely wrote in <76cede70-0558-ed62-7420-97e2e899e...@tana.it:

On Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote:

Murray S. Kucherawy wrote in 
:

On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso  wrote:
And couldn't it become standardized that verification results then 
must be included in future DKIM signatures?


Aren't you basically describing ARC here?


I am only talking DKIM.


Indeed, including and signing Authentication-Results is one of the two 
relevant differences between DKIM and ARC.


If in this [elided] example ietfa.amsl.com spends expensive CPU cycles to 
generate an authentication result, why is that not covered by the latter 
generated DKIM signature?


Because A-R fields were conceived for internal consumption.  Bastion 
hosts are supposed to remove or rename existing A-R fields while they add 
their own ones, so that downstream filtering modules can trustfully 
utilize the A-Rs they see. >>
The consideration you make, that A-Rs by a trusted forwarder can actually 
be useful came later.  Some experimented with Original-A-R fields.  Then 
the idea of DKIM-signing that stuff emerged, was discussed and resulted in 
ARC. It is a perfect tool for trusted forwarding. >>

Reinventing it is not necessary.


That is not my desire.  All i would ask for is that the (older
than ARC) DKIM signature a host generates is used to protect the
A-R that the host generated.



You may encounter a couple of problems signing A-Rs.  First, software that 
treats those fields probably removes or renames them on ingress, thereby 
breaking the signature.  To cope with that, you may want to slightly alter the 
header field name before signing it.  How about Original-Authentication-Results:?


Second, in case of multiple forwards, matching an A-R (or O-A-R) with the 
corresponding signature may become hazy.  Trace fields are always added at the 
top of the header and DKIM signs from the bottom up, but is it safe to rely on 
that for attributing reputation?  How about adding an explicit index?


That's what I called reinventing.


Best
Ale
--




___
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 Fri 11/Aug/2023 23:49:20 +0200 Steffen Nurpmeso wrote:

Alessandro Vesely wrote in <76cede70-0558-ed62-7420-97e2e899e...@tana.it>:

On Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote:

Murray S. Kucherawy wrote in 
:

On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso  wrote:
And couldn't it become standardized that verification results then 
must be included in future DKIM signatures?


Aren't you basically describing ARC here?


I am only talking DKIM.
If you DKIM sign a message and have an authentication result 
(made) available (yourself), anything but not including it in your 
own signature seems senseless.


Indeed, including and signing Authentication-Results is one of the two
relevant differences between DKIM and ARC.  The other is chaining existing
signatures. >

[...]

I think DKIM underspecifies which headers should be covered by the
signature.  This is all i want to say.



DKIM is very flexible by design.



If in this [elided] example ietfa.amsl.com spends expensive CPU cycles to
generate an authentication result, why is that not covered by the latter 
generated DKIM signature?


Because A-R fields were conceived for internal consumption.  Bastion hosts are 
supposed to remove or rename existing A-R fields while they add their own ones, 
so that downstream filtering modules can trustfully utilize the A-Rs they see.


The consideration you make, that A-Rs by a trusted forwarder can actually be 
useful came later.  Some experimented with Original-A-R fields.  Then the idea 
of DKIM-signing that stuff emerged, was discussed and resulted in ARC.  It is a 
perfect tool for trusted forwarding.


Reinventing it is not necessary.


Best
Ale
--




___
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 Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote:

Murray S. Kucherawy wrote in 
:

On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso  wrote:
And couldn't it become standardized that verification results then 
must be included in future DKIM signatures?
So then a verifier inserts a RFC 7001 header, and that will be 
covered by a further DKIM signature.


Aren't you basically describing ARC here?


I am only talking DKIM.
If you DKIM sign a message and have an authentication result 
(made) available (yourself), anything but not including it in your 
own signature seems senseless.



Indeed, including and signing Authentication-Results is one of the two relevant 
differences between DKIM and ARC.  The other is chaining existing signatures. 
I don't think considering DKIM plus A-R, that is ARC minus chaining makes any 
sense at this point.



Best
Ale
--






___
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

[Alessandro Vesely]

On Tue 08/Aug/2023 16:47:23 + Murray S. Kucherawy wrote:

On Tue, Aug 8, 2023 at 9:25 AM Alessandro Vesely  wrote:

On Tue 08/Aug/2023 14:47:37 + Murray S. Kucherawy wrote:

On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman  wrote:

That's true of all indirect mail flows.  It's not a distinguishing feature 
of the attack.


Quite right, making this harder to pin down.

But, to Alessandro's point, I do think the description in the document is 
accurate.


Agreed, except for narrating an actual case.  However widespread, there
are people like me who never recognized a replay attack.


What do you mean by "narrating an actual case"?  Section 1.1 does contain a
narrative of how one executes the attack.



Yes, it says DKIM Replay is impossible to detect or prevent with current 
standards and practices.  However, it must have been recognized well enough 
to grasp the described modus operandi.




Are you talking about a narration of how one detects the attack, as
distinct from a typical indirect mail flow?



I guess a replay attack must engage multiple abuse teams, because of the 
size.  Is the alarm triggered by users reporting many messages as spam? 
How many abuse teams at different organizations get involved?  What is the 
size of the attack?  What emergency measures are taken?  At what stage does 
it become clear that a spam tide is a Replay Attack?  What difference does 
it make such recognition?


I admit these questions are much out of curiosity, but knowing those 
details could help framing possible solutions.  Being completely ignorant 
about operations at large providers, I don't understand why the research 
steadfastly turns toward hard flying protocol changes rather than, for 
example, also investigating how to tune signing policies based on exchanged 
user reputation, or fast recognition of signed body hashes when they 
re-emerge from unexpected sources.



Best
Ale
--





___
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

[Alessandro Vesely]

On Tue 08/Aug/2023 14:47:37 + Murray S. Kucherawy wrote:

On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman  wrote:


That's true of all indirect mail flows.  It's not a distinguishing feature
of the attack.


Quite right, making this harder to pin down.

But, to Alessandro's point, I do think the description in the document is
accurate.



Agreed, except for narrating an actual case.  However widespread, there are 
people like me who never recognized a replay attack.



Best
Ale
--




___
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

[Alessandro Vesely]

On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote:

On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote:


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.



That's ambiguous.  Obviously, since the attack was planned, it may well be 
that the potential victims were originally intended.  The meaning is 
tweaked by the "normal usage" assumption, which could be interpreted as 
trying to pretend that the message author wasn't aware that the message was 
going to be replayed...?




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.



Would it be enough to say "Replay Attacks are described in Section 8.6 of 
DKIM", somewhere in Section 1.1 of the I-D?




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.



The definition cannot include a method to recognize the attack.  The I-D 
implies that attacks are being recognized (became commonplace), but omits 
the anecdotical narration of how it happens.



Best
Ale
--







___
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

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

[Alessandro Vesely]

On Tue 01/Aug/2023 16:09:03 + Tim Wicinski wrote:
Problem Statements may be published but are more importantly considered 
working documents with consensus from the working group.


We should get more "what didn't work" - people should send text !



I agree what-didnt-work can efficiently complement the problem description. 
 Yet, gory details should be relegated to apposite appendixes.



jm2c
Ale
--





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

Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D

[Alessandro Vesely]

On Thu 13/Jul/2023 05:33:44 +0200 Grant Taylor wrote:

On 7/12/23 9:26 AM, Wei Chuang wrote:

Being able to reverse mailing-list message modifications to repair the 
message and enable digital signature verification, would resolve a 
significant roadblock for further DMARC deployment.  Potentially it would 
allow better attribution of which party contributed which content in the 
message.  I propose some ideas around reversible mailing-list message 
modifications in: 
https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-00.  These modifications are: 1) prepending a description string to the Subject header, 2) rewriting the From header, 3) removing the original DKIM-Signature and 4) appending a footer to the message body.  (Apologies that -00 draft is still in a rough form)



(3) removing the original DKIM-Signature should never be done.  If it's removed 
there's no way you can verify it.  MLM often rewrite them, which implies they 
won't verify unless computed with the relaxed algorithm.




N.B. I've not read draft-chuang-replay-resistant-arc yet.



Me neither.



[...]
Old:

    Subject:  This is a test

Change:

    s/^Subject:\s+\(.*\)$/Subject:  [ietf-dkim] \1/



This would change:

Subject: Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D

to:

Subject: [ietf-dkim] Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D


I absolutely agree that regular expressions have problems and may open up a can 
of worms.  I'm mostly using them as a place holder for something, maybe a 
dialect of BNF, to describe the change.


I would think that such descriptions of 1) what was changed and 2) how the 
change was made would be more flexible than specifying specific things supported.



Wei's way to describe the change is probably better implemented by a 
post-transformation filter which has the original message available for 
comparison and can add all the Prior- headers.  That's because MLM often do 
change unwittingly, for example, from:


Content-Type: text/plain; charset="us-ascii"

to:

Content-Type: text/plain; charset="utf-8"

which is neither necessary nor documented, AFAIK.  It breaks signatures if the 
author domain signs Content-Type:.  I'm not clear where is the culprit. 
Over-signing causes other problems as well.



Grant's post arrived to me base64 encoded.  I think that's not how it was sent. 
 This kind of transformation is easily reversible.  However, reconstructing 
quoted-printable is not feasible.



For MIME parts, I recall Murray's draft provided for plain single part, mimw 
wrapped and mime added.  I never saw adding footers inside multiple parts.



Finally, I think there should be some limitations such as the footer being 
text/plain and not longer than a few lines, and subject tag being no longer 
than a couple of words.  That would likely protect the original intent of the 
message.



jm2c
Ale
--







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

Re: [Ietf-dkim] DMARC's auth=dkim+spf tag

[Alessandro Vesely]

On Fri 30/Jun/2023 19:22:28 +0200 Barry Leiba wrote:

Ale, you're venue-shopping; please don't do that.



Sorry, I understood the discussion was banned from the dmarc list.


In fact, messages that would only be blocked by auth=dkim+spf are either 
messages that pass DKIM but fail SPF, or messages that pass SPF but fail 
DKIM.  Since the latter case, excluding misconfigurations, looks unlikely, 
this settings serves only DKIM replay. >
What you say here about DKIM replay is misleading and wrong.  Barring 
misconfigurations, "dkim+spf" would be equivalent to "spf", as you 
actually point out in the paragraph above, and it has nothing to do 
with mitigating DKIM replay



An example of SPF pass where DKIM does not is a domain that uses an external 
smarthost, at least for some targets which blacklist its IP addresses.  A 
serious but non-exclusive smarthost can promptly identify abuse culprits, but 
may not be able to prevent them.  So checking DKIM in addition to SPF would 
bring an added value in such cases.



(other than to say that the way to avoid DKIM replay is not to pay attention 
to DKIM).


That agrees with the initial remarking that DKIM replay is a feature, not a 
bug, as it is consistent with the the by-design independence from transport 
details.



In any case, if anyone is interested in discussing this DMARC protocol 
proposal, please go to the DMARC list, where it is actively being 
discussed.



Anyway, discussing whether spf+dkim verification can mitigate DKIM replay 
belongs to the ietf-dkim list.  (In case, it could also be expressed outside 
DMARC, for example by an additional DKIM tag.)



Best
Ale
--




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

[Ietf-dkim] DMARC's auth=dkim+spf tag

[Alessandro Vesely]

Hi,

for those of you who don't subscribe to dm...@ietf.org, I resume this proposal, 
which was aired there last week.


The idea is to let a domain specify which mechanisms to consider when 
validating DMARC alignment.  The default would be auth=dkim/spf, meaning that 
either an aligned signature or an aligned SPF address would validate a message, 
as is now.


Setting auth=dkim only would change it to discard SPF results.  It could be the 
choice of domains who are forced to include an over-bloated SPF record, which 
is needed to deliver to some non-DMARC receivers, but allows impersonations.


Choosing auth=dkim+spf would require both DKIM /and/ SPF to validate.  That 
would exclude DKIM replay from unauthorized sources.  Would it work?  The 
effect could be compared to that of receivers who reject spf-all before DATA, 
hence before evaluating DKIM, and then would reject on failing or non-aligned 
DKIM.  The absence of softfail (~all) for DMARC would make the combined method 
even more severe, to the point that it's been called a footgun.


Discussions about solutions that only cover DKIM replay are now declared to be 
out of scope for DMARC.  In fact, messages that would only be blocked by 
auth=dkim+spf are either messages that pass DKIM but fail SPF, or messages that 
pass SPF but fail DKIM.  Since the latter case, excluding misconfigurations, 
looks unlikely, this settings serves only DKIM replay.  So I turn the topic to 
this WG, in case someone thinks it's worth mentioning it among the possible, 
yet untried solutions.



Best
Ale
--







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

Re: [Ietf-dkim] Problem statement adoption

[Alessandro Vesely]

On Fri 24/Mar/2023 18:42:28 +0100 Dave Crocker wrote:

On 3/24/2023 6:45 AM, Dave Crocker wrote:

On 3/24/2023 6:42 AM, Laura Atkins wrote:
We currently have two problem statements to discuss for adoption. 
Wei is merging 'mine' into his.  (Note mine was done as a variant of his.) 



For folks new to IETF processes, it might be worth explaining that 
contributions about an existing draft are usually anchored in specific 
suggestions for adding/changing/removing text.  This ensures that a) whatever 
concern is being raised is clearly linked to a specific part of the draft, and 
b) provides concrete, candidate text to evaluate.  This quite reliably develops 
movement towards document completion.


Sometimes, this process does not converge to the satisfaction of one or another 
participant.  Their usual response, then, is what I did: I wrote an 
alternative.  In my case it was explicitly derivative, with a goal of getting 
either chosen or merged.  In other cases, it might be completely independent.


Working groups often get bogged down debating concepts.  Having concrete text 
to review, debate, and decide about tends to mitigate against the infinite 
delay that staying at too high a level often produces.



Wouldn't make editing faster using GitHub tools?


Nest
Ale
--




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

Re: [Ietf-dkim] Replay Attack vs. something else

[Alessandro Vesely]

On Thu 23/Mar/2023 01:21:55 +0100 Dave Crocker wrote:
My understanding is that the term DKI MReplay Attack refers to a very specific 
scenario.


The scenario is re-posting a message such that the original DKIM signature
remains valid.

Any other sort of re-posting does not qualify, under this definition.



And this is the problem we're dealing with.  IOW, it's the PS.



So, for example, anything depending on 're-signing' is not a DKIM Replay Attack.

Yes?



Right, except that re-signing can be (part of) a solution to the problem.


Best
Ale
--





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

Re: [Ietf-dkim] Clarifying the problem

[Alessandro Vesely]

On Wed 22/Mar/2023 20:31:51 +0100 Michael Thomas wrote:

On 3/21/23 8:01 PM, Murray S. Kucherawy wrote:


 1. What percent of incoming email to a mailbox is through
    resenders and of that what percent resign?


By "resign" you mean something that has signatures from two domains, 
correct?  If so, how could one tell whether the originating operator did or 
did not attach one or more of them?


As in a mailing list makes a breaking change but resigns it with its own 
domain. The mailing could obviously sign their auth-res which if they have a 
good reputation the receiver might trust as a reasonable proxy.



That's reinventing ARC!

On Fri 10/Feb/2023 20:09:16 +0100 Michael Thomas wrote:
Again, drop the reference to ARC. it is: 1) Experimental, 2) the claim about 
it is wrong (DKIM can already sign a previous auth-res), and 3) this is the 
DKIM wg and it holds no power to make changes in it anyway.



I too used to be very skeptic about ARC (mainly because of the conjectured 
assumption that ARC sealers can be trusted based on an available reputation 
database, which skews usability toward global providers).  I changed my mind.


As a special flavor of DKIM designed around forwarding, ARC can bring real 
means to solving this problem.  Indeed, signing or sealing the messages to be 
forwarded can uncover the intent and the maker of the forwarding.



Best
Ale
--









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

Re: [Ietf-dkim] Welcome to the rechartered working group

[Alessandro Vesely]

On Mon 20/Mar/2023 07:04:11 +0100 Emanuel Schorsch wrote:

In my mind, there are two important things I would like to see achieved:

1) Distinguish indirect from direct flows (encode in some way which server / 
mailingList the original DKIM message was intended to come from). This is 
needed for domains that aren't easily identifiable as direct flows (SPF isn't 
aligned by DKIM in the direct case).



Rather, one could try and rescue the ethical nature of direct flows by 
understanding the forwarder.  Consider, for example, a message where To: or Cc: 
mention l...@example.net, and there is a signature which has d=example.net, and 
finally SPF validates example.net too.  The flow is indirect, but there's an 
easy inference in this case.


If it is clear why a message was forwarder from the original header recipient 
to the actual envelope recipient, then it has the same worthiness as if it were 
direct.



2) Give more info to identify benign indirect flows (E.g. "forwarded on behalf 
of"). This is helpful for recognizing a recipient's desired indirect flows.



In an attempt at classifying indirect flows in order to justify forwarding,I 
drafted this:

https://datatracker.ietf.org/doc/draft-vesely-email-agreement/

The idea is that forwarding requires to set up something where the target email 
address is explicit.  If that is legitimate, it can as well be published.




Note that this isn't to say indirect mail would be deprecated.



Indeed, it'd be self-contradictory to discuss here a document which deprecates 
mailing lists.



Best
Ale
--





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

Re: [Ietf-dkim] DKIM replay problem statement

[Alessandro Vesely]

Just a couple of comments on Jim's comments.  I don't quote the text on which I 
agree, unless I have to add to it.


On Tue 07/Mar/2023 23:46:18 +0100 Jim Fenton wrote:
To get things going, here are a few comments on 
draft-chuang-dkim-replay-problem-01:


Section 1.1:

[...]
“Bcc header field”: There is no Bcc header field. That would contradict the 
intent of bcc.



Bcc: is used by some command-line MUAs to derive the envelope.  Besides, some 
mailers copy Bcc:, one mailbox at a time, to each outgoing copy of the message, 
which is sent it to the relevant recipient only.




Section 2:

“Spammer may intentionally leave out certain headers”: RFC 6376 (section 5.4, 
last paragraph) recommends that signers sign all end-user visible header fields 
to avoid exactly this problem. This is really low-hanging fruit for a best 
practices document. I have no sympathy for domains that don’t sign (or 
over-sign, if they’re not present) these header fields and then suffer replay 
attacks.



For clarity, a clause should be added to explain the spammer's intent.  For 
example:


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


NEW
Taking advantage of the extended practice of not signing even important header 
fields if they are not present, the spammer may intentionally leave out some of 
them such as To:, and Subject: that can be added in later without damaging DKIM 
signatures which don't cover them.



While our chair has suggested we not focus on the solution space at this point, 
I have a couple brief comments on section 4.



According to our chair's suggestion, I'd drop Section 4 entirely.

Instead, I wish someone adds some information on the volumes and consequences, 
even anecdotal, of real cases.  Apropos reactions, albeit digressing into 
solution space, would be welcome in that context.



Best
Ale
--







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

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

[Alessandro Vesely]

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

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


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


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



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


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


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



Best
Ale
--




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

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

[Alessandro Vesely]

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

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

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

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


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


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


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



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


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


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


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



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



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



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


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



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



DNSWLs exist.


Best
Ale
--



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

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

[Alessandro Vesely]

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

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

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

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


Any idea when that might drop?


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

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



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



Best
Ale
--





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

Re: [Ietf-dkim] Setting a stage for detection

[Alessandro Vesely]

On Sun 12/Feb/2023 22:51:25 +0100 Dave Crocker wrote:

On 2/12/2023 1:44 PM, Murray S. Kucherawy wrote:
Would this work if it passes through more than one layer of aliasing? That 
is, can this work if "Separate-Envelope" appears more than once? Do they all 
have to be signed, order preserved, etc.?



Sounds like re-inventing ARC.


Best
Ale
--





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

Re: [Ietf-dkim] Chartering update

[Alessandro Vesely]

On Fri 03/Feb/2023 01:06:27 +0100 Scott Kitterman wrote:

There is an existing draft of a problem statement, so there's at least a 
starting point to consider.  I think discussion about what's needed is probably 
more useful relative to a specific draft than in the abstract:

https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/



It may be interesting to compare that document's Section 2, Mail Flow 
Scenarios, with pre-DKIM analysis depicted here:


https://commons.wikimedia.org/wiki/File:Mailflows-reloaded.png


Best
Ale
--








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

Re: [Ietf-dkim] Chartering update

[Alessandro Vesely]

On Sat 04/Feb/2023 00:44:35 +0100 Michael Thomas wrote:


On 2/2/23 4:06 PM, Scott Kitterman wrote:
There is an existing draft of a problem statement, so there's at least a 
starting point to consider.  I think discussion about what's needed is 
probably more useful relative to a specific draft than in the abstract:


https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/


Other than removing the ARC references, this seems like a good start.



ARC is very similar to DKIM.  Saying that it can have the same problem doesn't 
seem out of place to me.



I sort of like the proposed solution space, but several of them could be tried 
today or have huge downsides. Bcc, for example, would be a security fail if it 
were in the message headers. Caching signatures could be tried today but I 
don't see how that can be distinguished from, say, a mailing list.


But it could be rewritten in terms of not solutions but possible angles to 
attack the problem with pros and cons. It may well be that a preponderance of 
evidence could be useful. We could list off a bunch of other possible clues 
too. For one, what is the reputation of the To: address's domain? There are 
surely more.



I'd drop Section 4.  We have discussed those topics, but enumerating them in 
the problem statement sounds like establishing explicit limits to the solution 
space.


Rather, I'd include a report of actual incidents, possibly showing full message 
contents and estimated fallout dimensions.



Best
Ale
--







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

Re: [Ietf-dkim] sender signing practices

[Alessandro Vesely]

On Sat 04/Feb/2023 04:45:15 +0100 Michael Thomas wrote:

On 2/3/23 6:25 PM, Murray S. Kucherawy wrote:


But with respect to replay: Even if To and Cc are signed, there's nothing in 
DKIM requiring that they reflect any identities present in the envelope.


That's not the point. The point is that they are leaving clues to that the 
message is suspicious. Not signing To and Subject looks very sketch.


As I said: a preponderance of evidence. As always with spam detection.



Does that mean that, in case the submission server doesn't trust the current 
author, it should create a signature where To: and/or Subject: are not covered, 
in order to rise suspicion at receivers?


That sounds convoluted.  I still prefer i=bulshit...@gmail.com.


Best
Ale
--






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

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote:

On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
How about "replay-resistant protocol"? 


btw, it isn't clear that 'protocol' is what a solution will be. might be.  
might not.  might be purely operational conventions, for example.



That's right.  "Replay-resistant solution"?


Best
Ale
--





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

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Thu 05/Jan/2023 20:35:00 +0100 Dave Crocker wrote:

On 1/5/2023 11:03 AM, Wei Chuang wrote:



 2. Are there any other kinds of replay scenarios that are an issue now?
I suspect there aren't.


While not exactly ARC replay, we've seen recently that spammers are exploring 
munging the ARC headers.  One campaign had them swapping a complete ARC 
header set into another message.  In another they added an incomplete set.  
Consequently we're worried about the spammers exploiting ARC vulnerabilities.


There are some possibilities this suggests.

1. We could seek to explore and counter-act all (or a wide range) of replay 
scenarios, independent of their type or actual presence.  That is, both replays 
that are present in the wild and replays that are merely deemed possible, no 
matter how or why they do or might occur.



Well, that sounds like the best strategy in the long term, doesn't it?

For example, suppose we can sort out the few legitimate forwarding flows. 
Then, we could reject all mail where the envelope recipient doesn't match a To: 
or Cc: mailbox.  That would counter the vast majority of replay attacks.  And 
the techniques for doing so are much less tangled than signing the envelope.


Some times it is worth addressing the real weaknesses of a system, rather than 
some of the specific attack paths.



2. We could focus only on the know replay efforts so far, independent of type 
or degree of threat.


3. We could focus only on known, significant replay efforts.

4. and so on...

Of these, only 4 ensures focused, pragmatic efforts,



Eh?  You mean the "and so on..."?


Best
Ale
--






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

[Ietf-dkim] Yet another draft

[Alessandro Vesely]

Here's another idea to tell legitimate vs. abusive forwarding:

https://datatracker.ietf.org/doc/draft-vesely-email-agreement/


Best
Ale
--



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

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote:

I've added a few proposed milestones with dates


I wouldn't call "replay-resistant DKIM enhancement(s)" the deliverable.  I 
understand the WG name is DKIM, but two of the proposed drafts don't even 
mention it.  We may call ARC a "kind of DKIM", but a solution based on it would 
be better called an ARC enhancement, no?


How about "replay-resistant protocol"?


Best
Ale
--





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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Thu 15/Dec/2022 00:46:42 +0100 Jim Fenton wrote:

On 13 Dec 2022, at 17:00, Michael Thomas wrote:


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?


Some people use receive-side forwarders (e.g., college alumni addresses) to 
have a consistent email address if they change ISP. That will, completely 
legitimately, cause SPF failures on transactional email.



ale@pcale:~$ dig +short member.fsf.org txt
"v=spf1 ip4:0.0.0.0/1 ip4:128.0.0.0/1 ip6:0::/1 ip6:8000::/1 +all"


Best
Ale
--




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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Tue 13/Dec/2022 18:06:55 +0100 Evan Burke wrote:

On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton  wrote:


Is there anything that you can say about the types of domains whose
reputations are suffering as a result of replay attacks? Are they, for
example, small consumer mailbox providers, email sending providers, or
services that for some reason allow third parties to send (presumably
transactional) email through their servers?


Predominantly ESPs, but really anyone with substantial sending volume and
good reputation on the d= domain. ESPs seem to be the primary target
because they tend to have the highest sending volume, so the attacker can
send more replays before reputation and deliverability degrade.



Would someone please explain this trick to me, who never contacted an ESP?

From what I heard, I imagine someone opens new account at Mailchimp, say, 
creates a campaign and sends a test message to herself, which she will later 
replay.  How come it works every time?



Best
Ale
--







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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Mon 12/Dec/2022 15:50:44 +0100 Laura Atkins wrote:

On 12 Dec 2022, at 14:34, Murray S. Kucherawy  wrote:

On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely mailto:ves...@tana.it>> 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.


I’m not aware of Gmail being a significant victim here - although it’s possible 
they are.



I'm not aware of their taking any significant measure (after the effort, a few 
years ago, to reorganize all the different accounts on their different 
platforms.)  Yes, security has a cost.  Why are banks insisting on 2fA?



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.


They’re an identity of a known sender that invests time and resources into 
building and managing their reputation. Google? Maybe not. But the email 
service providers who do a lot to keep the spammers off their network are a 
common victim. These spammers know that they get better delivery if their mail 
is signed by the email service provider. The email service provider’s detectors 
and defenses are enough to stop the spammer from being able to send through the 
ESP. So the spammer sends one email to an account they own and takes a 
reputation they’ve already been told they shouldn’t be using.



I guess you refer to the same incident you touched on a few threads ago.  Did 
it happen more than once to the same ESP?  To more ESPs?  Cannot (did not) they 
configure their DKIM filter to not sign for untrusted prospects?




A DKIM signature is an identity. That identity has a reputation. Attacks that 
borrow the identity belonging to senders with good reputation benefit from that 
reputation. It’s not about any DKIM signature. It’s not about a random DKIM 
signature. It’s about a known entity. Even if Gmail only signed mail from 
accountable users, there is still the possibility of spammers posing as 
accountable users.



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


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?




The whole idea of a DKIM replay attack is that this is mail that cannot be 
directly sent through the infrastructure of the domain owner. That, itself, 
implies the domain owners are doing quite a bit to stop the spam from coming 
out of their network. If they weren’t doing a good job then replay attacks 
wouldn’t be happening - the mail would just be sent over that network directly.

Asking for the domain owners to “stop sending spam” when the whole replay 
process indicates they are stopping spam out of the networks they control seems 
a bit of a non-starter to me.



The securing activity you describe certainly has non-negligible costs.  Then 
why do we abhor the cost of classifying users?


Most likely, DMARC was branded as a requirement for email security and DKIM 
came as a consequence, without worrying too much about what is being signed. 
Replay attacks found the weak point of that paradigm.  Don't allow guests into 
secured areas of your premises.



Best
Ale
--






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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Sun 11/Dec/2022 21:52:46 +0100 Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 12:34 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.

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.


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



Best
Ale
--






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

Re: [Ietf-dkim] Problem Statement (OT)

[Alessandro Vesely]

On Fri 09/Dec/2022 16:47:47 +0100 Grant Taylor wrote:

On 12/8/22 5:17 AM, Alessandro Vesely wrote:

Those who do so are neatly classified as spammers.


On one hand I agree.  But on the other hand I disagree.

One benign case is that webmas...@example.com is configured to forward to 
al...@example.com so that Alice A. can perform her function.  Time goes by, 
Alice A. takes a job elsewhere.  Some time later, Alice B. starts and 
decides to re-use al...@example.com.  All the while nobody cleaned up 
webmas...@exmaple.com which is still forwarding to al...@example.com.  
Alice B. is in accounting and has nothing to do with and knew nothing about 
the webmas...@example.com forward until she started receiving complaints 
that she couldn't help with.


A slightly less benign case was years ago when I was dealing with an AOL 
sender and AOL had no interest in doing anything to stop the sender.  So I 
configured a forwarder to take messages from the sender, add them as an 
attachment to a message that cited the AOL internal case number to AOL's 
postmaster.  AOL's postmaster had no hand in requesting the forward.


I consider both to be legitimate, non-spam, forms of forwarding in which 
the recipient had no hand in the forward being put in place and likely 
couldn't easily change it if they wanted to.



The second case, forwarding to postmaster, looks perfectly legal.  It's not 
transparent forwarding.  A wrapped message is a 1st class message, with a 
new Message-Id: and a new From:.


The leftover case is difficult.  It needs attention to be diagnosed and 
repaired.  If it had a related whitelisting, it would also have to be 
teared down.




In addition, note that forwarded messages usually have a single recipient.


"usually" being the operative word.

Remember, original incarnation of mailing lists started as multi-recipient 
forwards / expansions at the MTA level.  Long before Mailing List Managers 
came into their own more proper existence.



Some Mailman configuration send with non-VERP bounce addresses.  Any way, 
single recipient is just a simplification.



Aside:  I'll maintain that we are still suffering from such multi-recipient 
expansion legacy today as many still do not treat the mailing list manager 
as it's own proper first class email recipient and originator and instead 
still consider it to be a bump in the path.



Well, I liked better when From: wasn't munged.



This makes it reasonable to set up per-recipient whitelists.


Please elaborate on what "per-recipient whitelists" means in this context.



Typical whitelist entries are set by the postmaster after careful 
evaluation.  Now, consider subscribing to a mailing list which does not 
munge From: (possibly as an option).  You need to whitelist the list 
domain, otherwise messages could be rejected after DMARC POLICY.  What if 
you're not the postmaster?


A mail site enabling per-recipient whitelisting would allow any user 
(recipient) to maintain her own whitelist.  I'd imagine that as a web form, 
where an authenticated user can fill the d= domain(s) to be whitelisted, 
not site-wide, but only for messages destined to her, under her 
responsibility.  I'd figure that she would fill the form for list.example 
along with her subscribing to the list.  If she subscribed as, say, 
alice+l...@example.com, she'd need to fill her alias as well.


The same can work for a single dot-forward.

I think that would be safer than blindly trusting ARC.

Best
Ale
--







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

Re: [Ietf-dkim] not removing signatures

[Alessandro Vesely]

On Wed 07/Dec/2022 18:49:47 +0100 Laura Atkins wrote:

On 7 Dec 2022, at 17:16, Barry Leiba  wrote:

The purpose of a DKIM signature is, as our original statement put it, to make sure that a message from your 
bank actually came from your bank, even if it passed through your alumni association. Once it arrives to your 
real mailbox, that signature is not needed.


As long as the signature is not removed in the alumni case I'm 
somewhat less concerned, but...


In some systems, sieve scripts and other filtering is done *after* the 
MUA drops the message in the delivery mailbox.  If that drop removes 
the signature, that hampers the sieve/filtering process severely.  A 
sieve "redirect" becomes impossible, and the filtering would not be 
able to use the DKIM signature for other purposes either (though it 
might be able to rely on the auth-results header field for some 
things.


That's what concerns me.


Maybe there’s a split the baby piece where part of the signature is stripped. 
I’ll be honest, the only bits I really look at are s= and d=. Maybe stripping 
part (bh?) while leaving the useful bits is a solution.



Isn't it the MDA which runs sieve filters?  Transparent forwarding is 
harder for a MUA, as it usually has to go through Submission protocol, 
which can change a number of message details.


RFC5598 distinguishes between hMDA and rMDA, delineating a logic point 
where a message transits from a state where it can still be forwarded and 
one where it's bound to local delivery.




Of course, that is not going to address the replay attack problem at all.



Agreed.


Best
Ale
--






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

Re: [Ietf-dkim] Problem Statement

[Alessandro Vesely]

On Wed 07/Dec/2022 16:49:55 +0100 Grant Taylor wrote:


On 12/7/22 2:59 AM, Alessandro Vesely wrote:

ARC is a good forwarding tool.


I question the veracity of that.  Mostly around -- what I consider to be -- 
the priming problem of getting a receiving system to trust an upstream 
system's ARC signature.



Some statements can be trusted.  For example, assume you apply DMARC and 
receive a message with no DKIM signatures and just an ARC set reporting 
that SPF failed for a p=reject domain.  The ARC sealer obviously didn't 
apply DMARC.  You can believe in its result and reject the message.


The opposite statement, that the message was valid when the forwarder got 
it, requires you to override DMARC.  As I said, I'd require the recipient's 
permission to do so.



Its semantic differs from DKIM as it implies no claim of responsibility.  
So it allows an MTA to forward a message as is, according to user's 
wishes, without bothering about receiver's policy.


I disagree.  The forwarding MTA has, can, and will continue to forward 
messages with or without ARC.  What ARC does do is add some information 
that the downstream receiving MTA /may/ use to make decisions.  The 
presence of ARC itself has no impact on the capability for an MTA to 
forward messages.



Agreed.  The point is that some decision can be harder without ARC.


That is, for example, if you don't enforce DMARC the receiver is still 
able to apply DMARC policies using trusted SPF results. In order to 
override DMARC policies, IMHO, the forwarder should be whitelisted by the 
recipient: an activity that could be automated, since forwarding to a 
different recipient requires prior agreement.


Forwarding to a different recipient does NOT require prior agreement. Full 
stop.



How do you pick up the target address?


Any MTA operator can configure their MTA to forward messages to whomever 
they want completely independently of the downstream receiving MTA's 
involvement, much less agreement.



Those who do so are neatly classified as spammers.

My Gmail account forwards to me because I asked it to do so.  My MTA 
forwards messages only to recipients who asked me to do that setting.  (And 
I put the bounce address to me, so I can text them when forwarding fails.)


This lists forwarded your message to me because I subscribed.

In addition, note that forwarded messages usually have a single recipient. 
This makes it reasonable to set up per-recipient whitelists.



Best
Ale
--






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

Re: [Ietf-dkim] Problem Statement

[Alessandro Vesely]

On Tue 06/Dec/2022 22:52:33 +0100 Michael Thomas wrote:
I think that any charter should specifically call out the need for a 
problem statement. The problem is far more nuanced than the few lines in 
the proposed charter and I think that the charter should be neutral about 
whether the problem can be solved because that isn't clear at all. Doing 
something to do something is how the ARC abomination came about, and we 
don't need to repeat that kind of  behavior.



ARC is a good forwarding tool.  Its semantic differs from DKIM as it 
implies no claim of responsibility.  So it allows an MTA to forward a 
message as is, according to user's wishes, without bothering about 
receiver's policy.  That is, for example, if you don't enforce DMARC the 
receiver is still able to apply DMARC policies using trusted SPF results. 
In order to override DMARC policies, IMHO, the forwarder should be 
whitelisted by the recipient: an activity that could be automated, since 
forwarding to a different recipient requires prior agreement.


A problem statement is draft-chuang-dkim-replay-problem.  It can be 
bettered, for example describing specific cases' actual volumes, 
involvement, damage and remedies.



In particular it needs to lay out the problems caused by the specific use 
case and how they overlap with legitimate use cases, and how complete that 
overlap is. It should also explore if there are ways to mitigate it with 
tools other than DKIM. Like for example, why is the sending domain signing 
spam in the first place?



Very much agreed, but that is still a DKIM question.


That should be the only deliverable from the wg along with an evaluation of 
whether the problem is tractable. If it is tractable, the wg should 
recharter with a plan of how to implement it.



Murray said it goes without saying that WGs can fail.


Best
Ale
--





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

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote:
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.



Please add the other Wei's I-D:
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/


Best
Ale
--





___
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)

[Alessandro Vesely]

On Tue 22/Nov/2022 01:21:00 +0100 Murray S. Kucherawy wrote:


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.



Indeed, there are products, like Lieser's DKIM verifier plugin for 
Thunderbird[*], which verify DKIM on the MUA.



Best
Ale
--

[*] https://github.com/lieser/dkim_verifier
https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/





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

Re: [Ietf-dkim] DKIM Replay alternative draft charter

[Alessandro Vesely]

While I like the terseness of Dave's text, its limiting the focus on DKIM may 
mislead.  It is natural to blame DKIM, but someone suggested that DKIM is 
working as intended even in replay attacks.  Indeed, differentiating a mailing 
list from a replay attack on the basis of signatures is difficult.  The 
solution space should include email authentication at large, possibly combining 
auxiliary techniques aimed at characterizing mail flows.


Best
Ale


On Sun 20/Nov/2022 18:08:48 +0100 Dave Crocker wrote:

Alternative draft charter text:

Domain Keys Identified Mail (DKIM, RFC 6376) associates a validated identifier with a 
message. This aids receiver assessment of the message flow using that identifier, 
improving reputation development and abuse detection.  A DKIM-signed message can be 
re-posted, to additional recipients, in a fashion that retains the original signature. 
With an author and a recipient collaborating, this can "replay" the message, 
using the original signer's reputation to propagate email with problematic content -- 
spam, phishing, and the like.

Generally, the technical characteristics of this form of abuse match that 
of legitimate mail, making its detection or prevention challenging. Timestamps 
and carefully-tailored message signing conventions are appealing approaches to 
replay mitigation.  Each has significant limitations.

The working group will develop technical specifications that describe 
abusive replay scenarios and provide mechanisms for detecting or preventing 
them.


It is always tempting to add quite a lot of commentary to a working group 
charter.  The challenge is to make sure that the commentary is technically 
correct and important to a charter, rather than a more general discussion.  For 
example, it used to be helpful to include reference to the initial drafts 
providing input to the effort, but current wg datatracker capabilities  make 
that unnecessary.


d/


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


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


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

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

[Alessandro Vesely]

On Thu 17/Nov/2022 00:56:12 +0100 Roland Turner wrote:

On 17/11/22 04:59, Alessandro Vesely wrote:


I fancied an experiment where a MLM offers a per-subscriber choice on whether 
to munge From: or not.  The way I envisaged it was to have users whitelist the 
ARC/ DKIM signing domain concurrently with their opting for non-munged From:. 
Mailbox providers could maintain per-user whitelists.  But it was rejected by 
the ISE...


That's a lot of moving parts. Quite apart from needing mailbox providers 
needing to provide a means to do this, it requires that the user making the 
munging decision act in concert with all of the other list subscribers (if I  
specify non-munging then all other subscribers must whitelist in order to 
receive my posts), which doesn't seem at all feasible.



No, it's the other way around.  If you opt for non-munging, then just the 
messages sent to you will not be munged, irrespective of the author.



Smaller mailbox providers operating without the benefit of security data 
of some sort, yes.


What security data?


Whatever a data provider might provide that's helpful. Most server-side 
anti-spam products already include some sort of data exchange (or at least 
feed) to allow decision-making by small receivers to be supported by a much 
broader picture of the behaviour of abusers than they can obtain from their own 
logs.



You mean DNSxLs, antivirus feeds, Pyzor and similar stuff?  Not any kind of MTA 
to MTA exchange?



Best
Ale
--





___
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

[Alessandro Vesely]

On Thu 17/Nov/2022 00:48:51 +0100 Roland Turner wrote:

On 17/11/22 04:34, Alessandro Vesely wrote:

On Wed 16/Nov/2022 05:35:52 +0100 Roland Turner wrote:

[ARC seals are] Not quite [enough], because they're not usually applied 
when a message is forwarded intact. One outcome of the proposed WG might 
be to specifically encourage all MLMs to ARC-sign, even if they don't 
break the author's DKIM signature, in this case to facilitate path 
reasoning in addition to coping with DKIM-breakage. >>
Right.  It'd be enough to require SPF pass of the last element of the chain, 
besides AMS verification.  That proves the ARC chain itself is not being 
replayed.  To me, it doesn't sound as an exaggerate requirement.


This is only true if the MTA hosting the MLM is the last element of the chain, 
which is not necessarily true.



Their SPF record has to account for the IP address of their bastion host.


It is also not the case that a forwarding MTA will always change the return 
path. meaning that there can quite reasonably be an SPF failure at this step 
for legitimate email.



Indeed, the correct sentence would be "to specifically encourage all /MTAs/ to 
ARC-sign even if they don't break signatures."  The requirement would only be 
needed for blindfolded messages —those whose recipients cannot be derived from 
To:/ Cc: fields.  However only the MUA, which creates the envelop, and the 
final MX, which interprets local parts, can know whether a message is blindfolded.



Best
Ale
--





___
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

[Alessandro Vesely]

On Wed 16/Nov/2022 05:32:24 +0100 Roland Turner wrote:

On 15/11/22 03:01, Alessandro Vesely wrote:

The exception is a standardised mechanism to allow a sender/signer to 
indicate the [approximate] number of intended recipients, with which 
receivers might make fact-based decisions about when to recognise an 
instance of this particular attack


For a mailing list, this is totally out of reach, unless the MLM itself is the 
(ARC) signer.


Your statement appears to assume that a message can have only one DKIM 
signature on it. This is not correct. The party-at-risk is the MLM who does not 
want to take any action. If they're willing sign — whether with ARC or DKIM — 
and include an approximate recipient count then they've provided potentially 
useful information for a receiver.



Your other message clarified this point.

Subscribers will probably appreciate to know how many people is lurking on a 
list.



In the context of a replay attack, the important cases are:

 1. the MLM does not break the original DKIM signature
 2. the MLM applies its own ARC/DKIM signature which is itself used in a reply
attack



I fancied an experiment where a MLM offers a per-subscriber choice on whether 
to munge From: or not.  The way I envisaged it was to have users whitelist the 
ARC/ DKIM signing domain concurrently with their opting for non-munged From:. 
Mailbox providers could maintain per-user whitelists.  But it was rejected by 
the ISE...




Even then, when the MLM knows there are 1000 subscribers, should
it extract the average per domain weight?  I mean if 500 are @gmail.com and
just 1 is @tana.it, should it extract the right figures for each receiver or
send a rough total,


As usual, the more help it can give receivers, the better receivers will do. 
Dividing as you suggest is likely to be useful.



Perhaps they could send 500/1000, so that everyone has a good knowledge of the 
mail flow.




which smaller mailbox providers cannot use?


Smaller mailbox providers operating without the benefit of security data of 
some sort, yes.



What security data?



BTW, we all know that mailing lists send one message at a time, doing VERP for
each subscriber.  They can more easily include the recipient in the ARC
signature.  However, any spammer can do the same.


Right, but this requires disclosing an identity that the spammer is trying to 
hide. This approach works better for legitimate users than for abusers, which 
makes it potentially useful.



Good point.  We want spammers to take responsibility.


Best
Ale
--






___
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

[Alessandro Vesely]

On Wed 16/Nov/2022 05:35:52 +0100 Roland Turner wrote:

On 15/11/22 23:10, Alessandro Vesely wrote:


On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote:
> On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely  wrote:
> >> BTW, we all know that mailing lists send one message at a time, doing >> 
VERP for each subscriber.  They can more easily include the recipient in >> 
the ARC signature.  However, any spammer can do the same. >
> WRT to the ARC like proposed approaches, agreed that the spammer can sign > 
for each recipient as well.  However then the spammer has identified > 
themselves in the path, and some future path aware reputation systems will > 
be able to distinguish the spammer from benign forwarding flows.



If you can filter basing on a reliable reputation system, current ARC seals are
enough already, aren't they?


Not quite, because they're not usually applied when a message is forwarded 
intact. One outcome of the proposed WG might be to specifically encourage all 
MLMs to ARC-sign, even if they don't break the author's DKIM signature, in this 
case to facilitate path reasoning in addition to coping with DKIM-breakage.



Right.  It'd be enough to require SPF pass of the last element of the chain, 
besides AMS verification.  That proves the ARC chain itself is not being 
replayed.  To me, it doesn't sound as an exaggerate requirement.



(I forget the IETF language for this, but there's a distinction between 
documents which specify protocols and documents which provide guidance on their 
use.)



Application Statement?


Best
Ale
--





___
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

[Alessandro Vesely]

On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote:

On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely  wrote:

BTW, we all know that mailing lists send one message at a time, doing 
VERP for each subscriber.  They can more easily include the recipient in 
the ARC signature.  However, any spammer can do the same. >
WRT to the ARC like proposed approaches, agreed that the spammer can sign 
for each recipient as well.  However then the spammer has identified 
themselves in the path, and some future path aware reputation systems will 
be able to distinguish the spammer from benign forwarding flows.



If you can filter basing on a reliable reputation system, current ARC seals are 
enough already, aren't they?



Best
Ale
--



___
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

[Alessandro Vesely]

On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote:
I'd point out that all but one of those things is either redundant (vs. say 
ARC), unacceptably harmful (we use DKIM *in the first place* to facilitate 
forwarding outside of the domain-registrant/sender's control), or both.



+1, Scott is right when he says DKIM is working as designed.



The exception is a standardised mechanism to allow a sender/signer to
indicate the [approximate] number of intended recipients, with which
receivers might make fact-based decisions about when to recognise an
instance of this particular attack



For a mailing list, this is totally out of reach, unless the MLM itself is the 
(ARC) signer.  Even then, when the MLM knows there are 1000 subscribers, should 
it extract the average per domain weight?  I mean if 500 are @gmail.com and 
just 1 is @tana.it, should it extract the right figures for each receiver or 
send a rough total, which smaller mailbox providers cannot use?


BTW, we all know that mailing lists send one message at a time, doing VERP for 
each subscriber.  They can more easily include the recipient in the ARC 
signature.  However, any spammer can do the same.



Best
Ale
--




___
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

[Alessandro Vesely]

On Mon 14/Nov/2022 01:26:29 +0100 Scott Kitterman wrote:



Because of DKIM’s broad deployment, compatibility with existing
deployments will be a critical factor, and it is unlikely that proposals
that lack compatibility will proceed to publication.


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.



What most approaches seem to imply is that a message which passes DMARC is 
acceptable when the recipient can be derived from one of the mailboxes in the 
To: and Cc: header fields  —let's call *blindfolded messages* those which miss 
this feature.  Email arch only authorizes to read To: and Cc: fields on 
sending, along with non-copied Bcc:, in order to derive the RCPT part of the 
envelope.


The solution we seek would imply to reject or quarantine non-whitelisted 
blindfolded messages, even if they pass DMARC.  This can be thought of as a 
further tightening of policies.  It would disrupt email architecture in a way 
similar to what DMARC itself does.  Indeed, DMARC charter does say that it is 
problematic for email architecture at large.  We should say the same here.



Best
Ale
--



___
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

[Alessandro Vesely]

On Sat 12/Nov/2022 19:46:13 +0100 Wei Chuang wrote:

On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman  wrote:

On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
> On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman  wrote:


If a domain is signing spam and their reputation suffers as a result, 
isn't that the system working as designed?



Yes, it is.



The slides
https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim-replay-problem-and-possible-solutions
at Dispatch and the problem statement draft
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem
help describe the DKIM replay problem.



Thanks!

I think Section 2, *Mail Flow Scenarios* lacks the case of secondary MXes, 
especially if they are provided by a different ADMD.


For a nit, *ESP Bulk Sender* has to be promoted to section title.



I think that between the draft and the discussion so far there are a few
classes of potential solutions:

1.  Signers have taken responsibility for the message when they signed 
it, so they get to live with the consequences of having done so (for this 
purpose, I think the "message" is the signed content of the message).  No 
standards action or changes required to DKIM, except maybe modernizing 
header field signing/over-signing recommendations to make replay at least 
a little more difficult.


That's the easiest thing to do.  Correctly listed as #1.


2.  Introduce changes that break existing indirect mail flows.  Standards 
actions needed.  Senders and receivers both need to make changes. 
Standards actions needed.  If we go down this path, would it be more 
honest just to declare indirect mail flows obsolete/deprecated (based on 
the prevalence of From re-writing on mailing lists, common practice may be 
headed this way already due to DMARC). >>
3.  Changes that modify expectations for legitimate indirect mail flows 
that illegitimate indirect mail flows such as replay attacks will have 
difficulty copying.  These require changes by senders, indirect mail 
processors (e.g. mailing list providers and forwarders), and receivers. 
Unlikely to be effective until widely implemented.


2 and 3 look the same to me.  We need to change something in the standards, and 
that would require to adjust the wording in the proposed charter, where it says:


compatibility with existing deployments will be a critical factor,
and it is unlikely that proposals that lack compatibility will
proceed to publication.


A way of bridging this, particularly for approach 3, is to use legacy 
authentication in addition to the replay resistant technique.  Use the 
replay resistant technique when available in preference to DKIM for DMARC 
and reputation systems, but have it available to fall back to.  A follow on 
consideration then is why would anyone adopt the new replay resistant 
technique.  Presumably there would be deliverability incentives for senders 
and forwarders to adopt the replay resistant technique (due to the negative 
reputation effects DKIM replay has) and for receivers to avoid escalations. 
In any case, I think the above categorization is pretty reasonable.


The two proposed replay resistant cryptographic domain based protocols that 
leverage ARC seem to be difficult to implement or a mailing list with thousands 
final recipients or a multi-hop forwarding.



What I've seen is that the Received header shows the delivery of the 
message to the initial recipient, followed by a new set of Received 
headers that shows that the message has been resent.  Sometimes the 
spammer leaves behind other clues like duplicate headers like multiple 
Date, Message-id or Subject headers.


We cannot rely on spammers' habits.

I'd rather note that recipients not in To:/Cc:, when legal, require prior 
arrangement.  Bcc:, depending on use cases, requires either an explicit or an 
implicit agreement.  Admins set up secondary MXes and inbound filtering 
services.  Users subscribe to mailing lists ans newsletters, and request 
forwarding (when used for email portability).  In addition, in the latter 
cases, messages to the final recipient have a single envelope recipient.  That 
feature can be used to setup per-user whitelists, to be updated concurrently 
with the subscription/ forwarding setup.



Best
Ale
--






___
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

[Alessandro Vesely]

On Fri 11/Nov/2022 12:42:26 +0100 Laura Atkins wrote:

On 11 Nov 2022, at 11:33, Alessandro Vesely  wrote:
On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote:

On 11 Nov 2022, at 05:04, Scott Kitterman  wrote:
[...]

For those that have been around for awhile this reminds me of the now long dead 
controversy about closing open relays.  It's not identical, but I think it 
rhymes.
Back in the mists of the early Internet we didn't have submission services 
because any client could send email via (most) any MTA, so they weren't needed. 
 As you can imagine, spamming was incredibly easy and the community gradually 
came around to the point that you can't just relay email for anyone, an MTA 
should serve authorized users (I oversimplify here).  As this consensus was 
being developed, a substantial number of MTA operators objected.  Eventually, 
being an open relay meant no one would take mail from you.
This seems similar.

I was around for the open relay discussions and I don’t see the parallels.


I do.

Going to a mailbox provider (MP[*]), obtain an email address, and send a 
message from it is paralleled to going to an open relay and send a message 
through it.  The only differences are (1) the From: domain is constrained by 
the MP, and (2) the MP requires me to interact with their web server in order 
to setup an address.  They both seem negligible to me.

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.



Indeed, identifying the message transport is the functionality we're thinking 
to retrofit into DKIM.




After all, DKIM was designed to allow discernment based on domain name rather 
than IP address.  No surprise that someone can abuse a domain name through 
different IP addresses.  A hasty and imprudent signature could easily cause 
risks.

Now, why does the MP take responsibility for unknown content?


They don’t. They take responsibility for the message.



Actually, they do.  They might have thought to control message transport, while 
in fact their control terminates when the message leaves their premises.




If we extend the open relays parallel, we'd forecast that allowing anonymous 
users to freely setup (hundreds of) email addresses has to come to an end.  Do 
MPs know the people they provide email services to?  If they do, they can 
afford the risk to put their reputation in their hands.

IOW, the simple solution is that free MPs send messages unsigned except for 
people they trust.


Just so I’m clear what you’re suggesting, what I’m hearing you say is that from 
Google, Yahoo, and Microsoft should be sent without a DKIM signature in the 
absence of some proof of identity for the sender?



Well, I don't dare suggesting it, because I'm unaware of the business model 
that free mailbox providers have in mind.  I know some (non-free) MPs know 
their users personally.  For them, signing shouldn't be a problem, because 
traitorous users would be expunged and never accepted again.  That way, the 
user/ provider relationship works both ways.  Are there reports of replay 
attacks by known users?


Anyway, yes, you understand me right.  I'm not suggesting, I'm forecasting.



[*] Previous messages use ESP, which I tend to associate to operators like 
Mailchimp, say, rather than Gmail.  I had a hard time trying to understand why 
ESPs would let folks send a single opt-in message...   Is it me?


Why wouldn’t they? I sent myself a test message to make sure it was right 
before triggering the send to a larger list (and, BTW, Mailchimp actually 
limits the number of tests you can do). It’s basic QA.



Were you really talking about ESPs?  I thought ESPs identify their (paying) 
customers.  If I replay Mailchimp signature they could sue me, couldn't they?


That's one of the reasons I asked for some kind of report.  I /imagine/ replay 
attacks go through free MPs signatures, because it looks like the easiest way.



Best
Ale
--





___
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

[Alessandro Vesely]

On Thu 10/Nov/2022 14:32:16 +0100 Steve Atkins wrote:
The other (more common?) case is that the original recipient is in the signed 
822.To, while the new recipient is not in the To: or Cc: headers at all. While 
that’s just the same as old-school alias forwarding, and you might not be able 
to spot that on any given single email I’d bet that it’s easy to spot and block 
at a mailbox provider of any size.


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”.



Or reject it outright unless the From: is in your address book.

Is it true that Bcc: is only used when there is a well established relationship 
between author and recipient?  For example, I use it to reach my Sent folder, 
and reject messages addressed to my Sent folder if they don't come from me.


OTOH, signing Bcc:s would betray their existence, although it can be done 
without revealing their content.



Best
Ale
--





___
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

[Alessandro Vesely]

On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote:


[...]

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 will start by considering those proposals; other
proposals remain welcome.



Isn't there a report on relevant replay attacks?  All the above I-D say that 
replay attacks are a problem.  Bron adds that the attack was widely seen in 
early 2022.  However, there's not a panoramic view of the problem, mentioning 
volume, scope, targets and such.


I know replay attacks are possible, but I never saw one.


Best
Ale
--




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

Re: [Ietf-dkim] DKIM replay mitigations

[Alessandro Vesely]

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


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



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


About formatting, don't stuff like:

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

If using XML[*], write references like:

ARC ()

Or, if using mmark[†]:

   ARC ([@!RFC8617])


Best
Ale
--

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







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

Re: [Ietf-dkim] DKIM replay mitigations

[Alessandro Vesely]

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


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

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

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


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



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




Regarding better supporting mailing lists:

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



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

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

There is no interest about it either.



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



Nope.



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


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



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




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



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



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



Best
Ale
--






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

Re: [Ietf-dkim] DKIM replay mitigations

[Alessandro Vesely]

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



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

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


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


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


Best
Ale
--


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

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

Re: [Ietf-dkim] [Technical Errata Reported] RFC6376 (6769)

[Alessandro Vesely]

On Wed 01/Dec/2021 15:00:36 +0100 Dave Crocker wrote:

On 12/1/2021 5:05 AM, Barry Leiba wrote:

The original text says exactly what it was intended to say, and is not
in error.  This is a suggestion for a change, not an errata report,



The reason to call it an error is that if a reader interprets that paragraph as 
alluding to the normal case that l= covers the whole original message, then she 
or he must conclude that the body can be altered without breaking the signature.




and I suggest closing it as "Hold For Document Update".


Yes.  Thanks.



+1

Best
Ale
--




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

Re: [Ietf-dkim] DKIM key rotation best practice

[Alessandro Vesely]

On 2020-08-07 5:53 a.m., Mark Delany wrote:
> On 06Aug20, Dave Crocker allegedly wrote:
>> M3AAWG DKIM Key Rotation Best Common Practices
>> (revised March 2019)
>>
>> https://www.m3aawg.org/DKIMKeyRotation
> 
> Luckily the tl;dr is in the first line. Phew! Quite the read :-)


Section 5.1.3 "Rotating Keys" is also worth reading, as it discusses
setting an empty p=.


> It seems that both Maawg and letsencrypt are both pro-automation. I
> think that's the biggest take-away for the OP.


That paper doesn't mention publishing the private key some time after
public key revocation.  Someone suggested to do so to avoid the
Clinton effect.


Best
Ale
-- 



























___
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

[Alessandro Vesely]

On Wed 13/May/2020 08:03:27 +0200 Murray S. Kucherawy wrote:
> 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.


It is a semantic addition about a question that people keeps asking.  Maybe its
usage becomes apparent once we get used to it, or maybe not.  It is the fact
that that question is frequently asked which triggered this thread and makes it
interesting.


>>> [...]
> 
> 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?


A-R details can be used to set IMAP keywords, to sort messages in different
folders, with varying colors or icons.  These techniques are quite helpful,
especially with busy mailboxes.

The destiny email messages is not a Boolean read-or-kill.


Best
Ale
-- 






























___
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

[Alessandro Vesely]

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.


> 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.

Hey, what if gmail used different selectors for newcomers?


Best
Ale
-- 










___
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

[Alessandro Vesely]

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...


Best
Ale
-- 






































___
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

[Alessandro Vesely]

On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote:
> On 5/11/2020 1:33 PM, Jim Fenton wrote:
> 
>> There might also be the situation where a domain wants to delegate a key
> 
> Hence my suggestion that figuring out such details is where discussion could
> get interesting, if only because people will raise all sorts of combinatorial
> theories, independent of demonstrated need, and this is a space with lots of
> combinatorials...


Besides delegated keys, some other obvious classes I'd propose —without
venturing to forge English keywords— are as follows:

* 1st class personal messages (with or without From: restrictions),

* mailing lists (with or without From: rewrite),

* bulk messages (including transactional confirmations, complaints, ...),

* forwarded mail (after severe/loose antispam filtering).

Perhaps, the keywords should be dash-separated jumbles of terms chosen from a
predefined grab bag, to allow for combinations.


On Mon 11/May/2020 21:52:28 +0200 Damon wrote:
> ... or is this only to add a layer of (potentially ignored) definitions?


Adding the definitions can be useful, given that so many people wonder about
what would a DKIM signature certify.


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.


On Mon 11/May/2020 19:30:10 +0200 Dave Crocker wrote:
> Oh, and then figuring out why and how they are useful to provide...


Left as an exercise to the reader?



Best
Ale
-- 



































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

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

[Alessandro Vesely]

Hi all,

consider the famous incipit:

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name [RFC1034] with the message [RFC5322], which
   they are authorized to use.

The question is, what responsibility is being claimed?  Some sites allow
authenticated users to use any From:, but are able to find out who the actual
author was, if needed.  Other sites only sign if the From: matches the actual
user, or at least its domain part.  Still others just sign everything.

Discussions about what kind of assurance would a signature imply are rather
frequent.  At least, specifying an aim= tag should shred some light on the
various possibilities.

Tagging keys with aim= would allow senders to choose an appropriate selector
under different circumstances.  Some mail sites use different sending IP
addresses to meet a similar purpose.  Others use different domain names, opaque
chunks of base64 data, or X-Google-DKIM-Signatures.  An aim= would serve a
similar purpose in a more open manner, introducing yet another means to discern
among different mail flows.

Comments?


Best
Ale
-- 






































___
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.

[Alessandro Vesely]

On Mon 17/Dec/2018 19:18:58 +0100 Fazzina, Angelo wrote:

> Sounds like my testing method may be flawed.  L


There are a number of sites for testing DKIM, for example:


sa-t...@sendmail.net
check-a...@verifier.port25.com
autorespond+d...@dk.elandsys.com
dkt...@exhalus.net
dkim-t...@altn.com
dkt...@blackops.org

In addition, one can try Gmail, Yahoo!, and the following three:
http://www.brandonchecketts.com/emailtest.php
http://www.appmaildev.com/en/dkim/
http://9vx.org/~dho/dkim_validate.php


HTH
Ale
-- 














___
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

[Alessandro Vesely]

Hi!

On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote:
> 
> I cannot provide very useful experience:

Thank you for the overview.  Albeit low-volume, it confirms my feeling that
rfc6651 is not widely adopted.

> [...]
>   - state explicitly that providers who want reports about mismatched
> DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=...

ruf= suffices.  p=reject;pct=0; is to force MLMs to rewrite From:, so as to
avoid useless reports.  However, what one deems useless could be interesting
for another; for example, one might use aggregate reports triggered by MLM
sending as a sort of delivery notification, thereby achieving a partial list of
subscribers' domains.  One-man-and-for-fun provider's subscription is easily
betrayed that way.


> Why shall software that knows r=y is old-fashion not remove it from
> DKIM-Signature:, in order to ensure that r=y is not interepreted later by
> software, that doesn't know r=y was moved to historic?

Let me recall that the DKIM-Signature header field is implicitly signed; that
is, if you alter it any way, it won't verify any more.  Removal of r=y would be
nearly impossible to undo, unless you know r=y was present and where exactly it
was placed.  Remove the whole field or rename it to, say, Old-DKIM-Signature.

BTW, some signatures are weak enough to survive boilerplate changes.  In that
case, the signer might be interested in verification failures even after MLM
changes.  How would you treat that instance?

Best
Ale
-- 



___
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

[Alessandro Vesely]

On Sat 18/Aug/2018 23:45:40 +0200 Murray S. Kucherawy wrote:
> 
> 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.

The difference w.r.t. DMARC is that it is the signer, not necessarily the
author's domain owner, who gets the report.  So, yes, rfc6651 has its own
worthiness.  The part related to ADSP, however, deserves to be demoted to 
Historic.

IMHO, updating rfc665{1,2} should be done after rfc7489bis, moving the format
definitions to the latter spec, for the reasons explained in my previous 
message.

Best
Ale
-- 


___
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

[Alessandro Vesely]

Hi all!

On Sat 11/Aug/2018 05:38:40 +0200 Dilyan Palauzov wrote:
> 
> RFC6651 (Extensions to DomainKeys Identified Mail (DKIM) for Failure 
> Reporting)
> adds to DKIM-Signature the couple r=y - when an existing DKIM-Signature does
> not validate, the signing server is notified that something went
> (unintentionally) wrong.

Interesting.  I knew about rfc6651, but never cared to implement it.  Would you
write for those like me a short overview of your experience with your
arf+dkim-report mailbox, mentioning e.g. how long have you implemented it for,
the rough amount of reports / reporting domains that hit it, and the like, 
please?

> 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.

Perhaps, rfc7489 is not very clear in the explanation of dmarc-fo.  Does fo=d
provide for sending a report irrespectively of r=y?  MDaemon's implementation,
for one, interprets the reference to rfc6651 as a requirement for requesters to
set r=y in their DKIM signatures:

   When the DMARC "fo=" tag requests reporting of DKIM related failures,
   MDaemon sends DKIM failure reports according to RFC 6651. Therefore, that
   specification's extensions must be present in the DKIM-Signature header
   field, and the domain must publish a valid DKIM reporting TXT record in DNS.
   DKIM failure reports are not sent independent of DMARC processing or in the
   absence of RFC 6651 extensions.
 http://help.altn.com/mdaemon/en/security--dmarc_reporting.htm

> RFC6377 (DomainKeys Identified Mail (DKIM) and Mailing Lists) suggests in
> section 5.7 to remove the invalidated DKIM-Signagures, if the mailing list
> software has changed the email.
> 
> I have not read ARC, but I have the impression that it says to keep the
> invalidated DKIM-Signatures.
> 
> When an email with DKIM-Signagure: r=y is sent to a mailing list, the email is
> modified, and a final recipient following r=y sends a report.  The problem is
> that this report is useless and distracting - it does not indicate, that the
> signer-MTA or validator-MTA are implemented in wrong way.

Correct.  MLMs affect DMARC too.

> 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.  Let me skip the long winded story of the
ideas for solving the MLMs problem of DMARC.  Suffice it to say that there is a
dmarc WG[*], which is where ARC comes from.

Meanwhile, the MLMs problem is being solved by rewriting From:.  This doesn't
help r=y.  However, I'm reluctant to elect to rewrite DKIM signatures.  A
broken signature can still be recovered by manually undoing the obvious
modifications applied by MLMs, see attached screenshot.

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.


Best
Ale
-- 

[*] https://datatracker.ietf.org/wg/dmarc/about/

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