On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
> DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and
> receivers opt in to use them. Both sides are necessary. So I'm wondering
> about looking for something the furthers the collaboration.
The lack of reporting to the originating DKIM signers about Replay and other
kinds of DKIM failure modes is an example of "limitations at the sending side
[...] trying to detect". Alex and I are starting to draft a proposal for
receivers to report to signers using rfc5965 and rfc7489 semantics.
Even with the best FBLs, it is too reactionary to prevent the "single message"
from slipping through, not to mention all of the other scenarios discussed in
this conversation. The originator has to make a boolean decision, based on
limited and untimely information, about whether to send the message. So, we
need a mechanism for receivers/evaluators to look up additional information
about the context in which the message was originally signed (i.e. Ale's "Use
segmented signature domains")
Does it make sense to address the evaluator-->signer and signer-->evaluator
feedback problem in a unified document, or keep them separate?
I have thoughts that an out of band lookup mechanism (i.e. via signer-hosted
DNS policy/intent records and signer-hosted DNSxL hash tables keyed on d=
domains) is needed for evaluators to understand the meaning of the different d=
subdomain signatures that a signer has applied to a message.
> And the attacker can't bypass it, if the signature covers enough (or all) of
> the message.
>
The "new header field" (or similar) approach alone would not open any doors for
revocation/invalidation of the fact that the signature was applied on that
first single message. Relying solely on fast key rotation/invalidation would
mean TTLs would need to be very low to have any effect.
Jesse
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
