Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal
On Thu 22/Jun/2023 19:34:43 +0200 Jan Dušátko wrote: Dne 21. 6. 2023 v 10:59 Alessandro Vesely napsal(a): On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote: Our proposal would be for DMARCbis to maintain the default for SPF and DKIM support, and to support senders that want to drop SPF as one of their DMARC authentication methods to avoid the SPF upgrade vulnerability. After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, besides or and one only, for domains that want that extra security. Possible values, for example, auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf. Possibility of choosing policy based on evaluation of the SPF, SPF and DKIM, SPF or DKIM event. DKIM itself in DMARC2 will be really helpful. In case of DKIM and SPF need to pass, seems to be little bit different results than previous. This will definitely satisfy me for thousands of domains. Requiring both DKIM and SPF to be aligned and verified is very harsh. Forwarding would be disallowed, except for specific agreements. It wouldn't be handy for general purpose mail domains, but could beat replay in some cases. Albeit reckless users would have the possibility to shoot their own feet, DMARC aggregate reports should provide a good forecast of the results. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal
Dne 21. 6. 2023 v 10:59 Alessandro Vesely napsal(a): On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote: Our proposal would be for DMARCbis to maintain the default for SPF and DKIM support, and to support senders that want to drop SPF as one of their DMARC authentication methods to avoid the SPF upgrade vulnerability. We could have a DMARC policy tag for authentication e.g. "auth=" that describes the permitted authentication methods the sender supports and receiver MUST use for validation. DKIM or SPF are represented as tags "dkim" and "spf", and if multiple tags are present then they are comma separated and any one passing is considered passing authentication. Also at least one authentication method MUST be present. Other authentication methods could be added in the future as it is our hope that there will be some other authentication method to improve upon and someday replace SPF. overall. If "auth=" is missing, then DMARC falls back to supporting SPF and DKIM. +1, clarifying underlying mechanisms improves DMARC usability. Version bump only forces domains that wish to use the new tag to create a new v=DMARC2 record. Old evaluators will read the v=DMARC1 record, whereas they can just ignore the new tag if we stick to the same version. After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, besides or and one only, for domains that want that extra security. Possible values, for example, auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf. Best Ale Ale, If I understand DMARC well, right now works in mentioned way. The fo= are for reporting only and I have seen many implementation, which simply ignore it, they used the same condition as DMARC have. To be honest, I does not sure if my understanding are correct, please do not hesitate and correct me if I'm wrong. if ((SPF=pass) and (SPF aligned with "From" domain)) or ((DKIM=pass) and (DKIM aligned with "From" domain)) then DMARC=pass +---++---+-+--+ | Alignment | Result | Alignment | Result | Result | | of SPF | of SPF | of DKIM | of DKIM | of DMARC | +---++---+-+--+ | Failed | Failed | Failed | Failed | Failed | | Failed | Failed | Failed | Pass | Failed | | Failed | Failed | Pass | Failed | Failed | | Failed | Failed | Pass | Pass | Pass | | Failed | Pass | Failed | Failed | Failed | | Failed | Pass | Failed | Pass | Failed | | Failed | Pass | Pass | Failed | Failed | | Failed | Pass | Pass | Pass | Pass | | Pass | Failed | Failed | Failed | Failed | | Pass | Failed | Failed | Pass | Failed | | Pass | Failed | Pass | Failed | Failed | | Pass | Failed | Pass | Pass | Pass | | Pass | Pass | Failed | Failed | Pass | | Pass | Pass | Failed | Pass | Pass | | Pass | Pass | Pass | Failed | Pass | | Pass | Pass | Pass | Pass | Pass | +---++---+-+--+ Possibility of chosing policy based on evaluation of the SPF, SPF and DKIM, SPF or DKIM event. DKIM itself in DMARC2 will be really helpful. In case of DKIM and SPF need to pass, seems to be little bit different results than previous. This will definitely satisfy me for thousands of domains. if ((SPF=pass) and (SPF aligned with "From" domain)) and ((DKIM=pass) and (DKIM aligned with "From" domain)) then DMARC=pass +---++---+-+--+ | Alignment | Result | Alignment | Result | Result | | of SPF | of SPF | of DKIM | of DKIM | of DMARC | +---++---+-+--+ | Failed | Failed | Failed | Failed | Failed | | Failed | Failed | Failed | Pass | Failed | | Failed | Failed | Pass | Failed | Failed | | Failed | Failed | Pass | Pass | Failed | | Failed | Pass | Failed | Failed | Failed | | Failed | Pass | Failed | Pass | Failed | | Failed | Pass | Pass | Failed | Failed | | Failed | Pass | Pass | Pass | Failed | | Pass | Failed | Failed | Failed | Failed | | Pass | Failed | Failed | Pass | Failed | | Pass | Failed | Pass | Failed | Failed | | Pass | Failed | Pass | Pass | Failed | | Pass | Pass | Failed | Failed | Failed | | Pass | Pass | Failed | Pass | Failed | | Pass | Pass | Pass | Failed | Failed | | Pass | Pass | Pass | Pass | Pass | +---++---+-+--+ Regards Jan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal
On Wed 21/Jun/2023 23:24:57 +0200 John Levine wrote: It appears that Alessandro Vesely said: After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, besides or and one only, ... I am reasonably sure that when DMARC was designed they considered that and rejected it. Perhaps the landscape slightly changed since? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal
It appears that Alessandro Vesely said: >After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, >besides or and one only, ... I am reasonably sure that when DMARC was designed they considered that and rejected it. So, no, and certainly not at this late state in the WG. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal
On Wed, Jun 21, 2023 at 1:59 AM Alessandro Vesely wrote: > After sleeping on it, I think the new tag could also specify DKIM /and/ > SPF, > besides or and one only, for domains that want that extra security. > Possible > values, for example, auth=dkim|spf (default value), auth=dkim+spf, > auth=dkim, > auth=spf. > +1 to the spirit, but I think the meaning needs to be clarified. It adds value to allow domains that have control of the SPF to indicate that receivers should expect SPF and DKIM to both be DMARC aligned in the direct mail case. This provides a very useful signal to apply DKIM Replay mitigations if that's not the case. But if the policy is also p=reject that would be essentially saying "this mail should never be forwarded". That seems unreasonable, but saying DKIM needs to be aligned for DMARC to pass, and if SPF isn't aligned then consider the message a potential DKIM replay case. Though I don't know if that indicator belongs in the auth tag, or would be better as a separate parameter. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal
On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote: Our proposal would be for DMARCbis to maintain the default for SPF and DKIM support, and to support senders that want to drop SPF as one of their DMARC authentication methods to avoid the SPF upgrade vulnerability. We could have a DMARC policy tag for authentication e.g. "auth=" that describes the permitted authentication methods the sender supports and receiver MUST use for validation. DKIM or SPF are represented as tags "dkim" and "spf", and if multiple tags are present then they are comma separated and any one passing is considered passing authentication. Also at least one authentication method MUST be present. Other authentication methods could be added in the future as it is our hope that there will be some other authentication method to improve upon and someday replace SPF. overall. If "auth=" is missing, then DMARC falls back to supporting SPF and DKIM. +1, clarifying underlying mechanisms improves DMARC usability. Version bump only forces domains that wish to use the new tag to create a new v=DMARC2 record. Old evaluators will read the v=DMARC1 record, whereas they can just ignore the new tag if we stick to the same version. After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, besides or and one only, for domains that want that extra security. Possible values, for example, auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
