Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We are talking about SPF AND DKIM because of the problems with DKIM > replay. Can someone summarize the state of the DKIM update options that > have been ruled in or ruled out? > There's a document over in that working group that takes a run at doing so. I'm worried about the complexity and assumptions in the proposal that follows: Given a received sequence of > >- Msg Date >- Rcv Date 1 >- Rcv Date 2 >- >- Rcv Date N > > A signature should have a start time between one of these date boundaries. > There's no reason to trust the dates, IP addresses, or any other detail in these header fields beyond infrequent manual diagnostic efforts. They are trivially forged and rarely signed. You definitely should not attempt to couple anything you infer from them with the semantics of a passing cryptographic signature. The first global IP after the signature server becomes the perimeter server > which must demonstrate that it's domain has the right to act on behalf of > the signing domain. > That sounds like the very definition of SPF. By "global" I presume you mean "publicly routed". Do we really want to start teaching mail software how to determine which IP addresses are publicly routed? It's not as simple as the RFC 1918 question. Improvements within control of the signing server: > > If the message is not created by the originating server, the message > should contain one or more Received headers. The header list on the > signature should contain "Received" entries to match the number of Received > headers at the time of signing. This further identifies the signature's > position in the Received chain. > The original DKIM RFC (RFC 4871) specified a list of header fields that SHOULD and SHOULD NOT be signed, and Received was in the latter group. It's common for Received fields to be stripped when they depart a domain in order to conceal the topology within that domain. Less commonly, they can get reordered, edited, or re-wrapped. Any of those would break the signature if it covered them. RFC 6376, the standard, dropped the SHOULD and SHOULD NOT, but still discourages paying any attention to Received when signing. > Improvements requiring changes to the DKIM specification > > They could identify a way to document the signing server's domain in the > signature. > Isn't that the "d=" tag? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We are talking about SPF AND DKIM because of the problems with DKIM > replay. Can someone summarize the state of the DKIM update options that > have been ruled in or ruled out? > I'll clarify how I view SPF AND DKIM in relation to DKIM Replay. Let's use bob.com as the domain: - If DK=bob.com and SPF=bob.com then NOT dkim replay. - If DK=bob.com and SPF!=bob.com then MAYBE dkim replay (of course probability of dkim replay varies widely, and could still be 0 for this particular SPF) - If DK=bob.com and SPF!=bob.com and DMARC policy is SPF AND DKIM then LIKELY dkim replay if seen in large volumes. So the value of that DMARC policy for DKIM Replay is that bob.com can be better protected against heavy replays because they have a way to say "I've checked all my direct flows have SPF AND DK aligned. If you see mail with a different SPF you can be sure it's an indirect flow and be more aggressive about quota limiting large volumes." To be clear, that would be a benefit for protecting aligned domains that are replayed, but I'm NOT suggesting this is enough benefit to allow users to set SPF AND DKIM for a DMARC auth policy. I agree with others that it's a footgun, and it would be better to convey this information in some other way. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
We are talking about SPF AND DKIM because of the problems with DKIM replay. Can someone summarize the state of the DKIM update options that have been ruled in or ruled out? We have the DARA proposal from Google, which is related to signature replay, but focused on ARC. I am guessing that it correlates closely to the DKIM updates. Should the discussion move to that draft for a bit? I also look forward to Scott's ideas. DARA limits replay by linking the signature to a recipient. An alternative approach is to limit replay be linking the signature to a source server. It may be less effective, but some benefit can be gained from this approach, which does not require a DKIM rewrite. Here are my thoughts: Given a received sequence of - Msg Date - Rcv Date 1 - Rcv Date 2 - - Rcv Date N A signature should have a start time between one of these date boundaries. - If the signature start time is equal to, or shortly, after, a Received header timestamp, the signing server is the BY server which create the Received header. - If the signature start time is prior to any Received header timestamp, but on or after the message Date header, then the FROM information on the first Received header identifies the signing server. - If the signature start time is prior to the message Date header, the signature looks suspicious In some cases, clock skew may create ambiguity about the signing server. Even when this occurs, the ambiguous servers are likely to lie behind the same perimeter server, so the ambiguity may not need to be resolved. The first global IP after the signature server becomes the perimeter server which must demonstrate that it's domain has the right to act on behalf of the signing domain. - We do an SPF test on the perimeter server's IP address and the signature domain. If this test produces SPF PASS, the signature has enhanced trust. - If the perimeter server domain matches the signature domain, and the perimeter server host name can be forward confirmed to its IP address, this provides an alternative to SPF PASS. - If either test succeeds, the risk of DKIM reply is significantly lessened. If neither test succeeds, then the signature risk of DKIM replay is greater Improvements within control of the signing server: If the message is not created by the originating server, the message should contain one or more Received headers. The header list on the signature should contain "Received" entries to match the number of Received headers at the time of signing. This further identifies the signature's position in the Received chain. Improvements requiring changes to the DKIM specification They could identify a way to document the signing server's domain in the signature. Then the perimeter server host names can be tested to see if they match the signature's server domain and can be forward-confirmed to the Source IP. This provides an alternative to SPF for configurations where the server domain and the signature domain are different organizations. Doug Foster On Wed, Jun 28, 2023 at 3:44 PM Scott Kitterman wrote: > I think it's quite relevant. > > The assumption that this is based on is there's a need to specify because > SPF data is not reliable enough for everyone. If that premise is correct > (I don't agree with it, but it's a separate issue), then I think telling > people that they should use DKIM because it IS reliable, when it's got its > own issues isn't a great idea. > > I've been mulling this whole topic over and I think I'm close to having > mulled it enough to have a useful proposal. SPF bad, DKIM good is a gross > over-simplification, but so is if it passed SPF, it's authorized, so go > whine at the provider. > > Scott K > > On June 28, 2023 6:32:41 PM UTC, Barry Leiba > wrote: > >I think DKIM replay is largely irrelevant to this discussion (about > >the sender specifying which authentication to use), because if that's > >your biggest concern with respect to DMARC, then "SPF only" is the > >answer. "SPF *and* DKIM" is not any better than that. > > > >> You seem to imply that auth=dkim+spf wouldn't be effective against DKIM > reply > > > >(Assuming you mean "replay".) "SPF and DKIM" does not give any > >benefit beyond "SPF only" in this case. > > > >Look, either SPF fails because the message was relayed illegitimately... > >...or SPF passes because the replayer used the sender's legitimate > >infrastructure to do the replay. > > > >Barry > > > >On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely > wrote: > >> > >> Thank you for your analysis. However, it doesn't touch on DKIM replay. > >> > >> I know this topic belongs to the other list. Let me briefly recall it, > if this > >> doesn't take too many cycles from core matters: It occurs when a signed > >> message is replayed by unauthorized hosts to recipients which were not > >> originally addressed. So, it is one case of your 3rd proposition
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
I think it's quite relevant. The assumption that this is based on is there's a need to specify because SPF data is not reliable enough for everyone. If that premise is correct (I don't agree with it, but it's a separate issue), then I think telling people that they should use DKIM because it IS reliable, when it's got its own issues isn't a great idea. I've been mulling this whole topic over and I think I'm close to having mulled it enough to have a useful proposal. SPF bad, DKIM good is a gross over-simplification, but so is if it passed SPF, it's authorized, so go whine at the provider. Scott K On June 28, 2023 6:32:41 PM UTC, Barry Leiba wrote: >I think DKIM replay is largely irrelevant to this discussion (about >the sender specifying which authentication to use), because if that's >your biggest concern with respect to DMARC, then "SPF only" is the >answer. "SPF *and* DKIM" is not any better than that. > >> You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply > >(Assuming you mean "replay".) "SPF and DKIM" does not give any >benefit beyond "SPF only" in this case. > >Look, either SPF fails because the message was relayed illegitimately... >...or SPF passes because the replayer used the sender's legitimate >infrastructure to do the replay. > >Barry > >On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely wrote: >> >> Thank you for your analysis. However, it doesn't touch on DKIM replay. >> >> I know this topic belongs to the other list. Let me briefly recall it, if >> this >> doesn't take too many cycles from core matters: It occurs when a signed >> message is replayed by unauthorized hosts to recipients which were not >> originally addressed. So, it is one case of your 3rd proposition: In some >> scenarios, DKIM will pass when SPF fails. >> >> You say that it is technically unnecessary to test both because DKIM should >> always pass when SPF passes (1st proposition). >> >> You claim: >> > But where the harm comes is in cases of mis-configuration, because now if >> > *either* of them is misconfigured, the whole thing fails -- neither of them >> > serves as a backup for the other; instead, the misconfiguration of either >> > one causes deliverability problems. >> >> >> I agree. But what if SPF and DKIM are both configured properly? You seem to >> imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your >> analysis doesn't cover that case explicitly. >> >> Perhaps there are better ways to counter that specific problem, and certainly >> it's not what this WG is tasked to do. But, just to make the point, I think >> it's interesting to know. >> >> >> Best >> Ale >> >> >> On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote: >> > I don't understand how most of your message fits into this discussion: >> > you're comparing SPF's policy points with DMARC policy. we're talking >> > about SPF as an authentication mechanism together with DKIM (not >> > DMARC) as an authentication mechanism... and then using those >> > authentication results in DMARC policy evaluation. >> > >> > But here: I've said all this before in separate places, so I'll put it >> > in one place, here, one more time: >> > >> > Given that SPF and DKIM are both configured properly: >> > 1. If SPF passes, DKIM will always pass. >> > 2. If DKIM fails, SPF will always fail. >> > 3. In some scenarios, DKIM will pass when SPF fails. >> > >> > Therefore, when everything is configured properly, SPF adds no value >> > beyond what DKIM does, and DKIM does add value beyond what SPF does. >> > That's why I am (and others are) arguing that we should remove SPF >> > *from DMARC evaluation*. There's no argument that for now, or some, >> > SPF outside of DMARC still has value. >> > >> > What others are arguing is that in the real world, things do get >> > mis-configured, and if DKIM is misconfigured and fails when it >> > shouldn't, SPF adds value by providing a working authentication. >> > (And, of course, similarly the other way around, plus DKIM covers some >> > cases when messages are relayed or forwarded.) That speaks for "SPF >> > *or* DKIM". >> > >> > But "SPF *and* DKIM" -- requiring *both* to pass -- is technically >> > unnecessary at best, because of (1) above: DKIM should always pass >> > when SPF passes. But where the harm comes is in cases of >> > mis-configuration, because now if *either* of them is misconfigured, >> > the whole thing fails -- neither of them serves as a backup for the >> > other; instead, the misconfiguration of either one causes >> > deliverability problems. DMARC is damaged by requiring an >> > authentication situation that is unnecessary when things are properly >> > configured, and that is more fragile than what we've been using, more >> > susceptible to configuration errors than we've seen before. >> > >> > And I'm afraid that people will use it preferentially, *thinking* that >> > it provides better "security" -- surely, double authentication is >> > better
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
I think DKIM replay is largely irrelevant to this discussion (about the sender specifying which authentication to use), because if that's your biggest concern with respect to DMARC, then "SPF only" is the answer. "SPF *and* DKIM" is not any better than that. > You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply (Assuming you mean "replay".) "SPF and DKIM" does not give any benefit beyond "SPF only" in this case. Look, either SPF fails because the message was relayed illegitimately... ...or SPF passes because the replayer used the sender's legitimate infrastructure to do the replay. Barry On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely wrote: > > Thank you for your analysis. However, it doesn't touch on DKIM replay. > > I know this topic belongs to the other list. Let me briefly recall it, if > this > doesn't take too many cycles from core matters: It occurs when a signed > message is replayed by unauthorized hosts to recipients which were not > originally addressed. So, it is one case of your 3rd proposition: In some > scenarios, DKIM will pass when SPF fails. > > You say that it is technically unnecessary to test both because DKIM should > always pass when SPF passes (1st proposition). > > You claim: > > But where the harm comes is in cases of mis-configuration, because now if > > *either* of them is misconfigured, the whole thing fails -- neither of them > > serves as a backup for the other; instead, the misconfiguration of either > > one causes deliverability problems. > > > I agree. But what if SPF and DKIM are both configured properly? You seem to > imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your > analysis doesn't cover that case explicitly. > > Perhaps there are better ways to counter that specific problem, and certainly > it's not what this WG is tasked to do. But, just to make the point, I think > it's interesting to know. > > > Best > Ale > > > On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote: > > I don't understand how most of your message fits into this discussion: > > you're comparing SPF's policy points with DMARC policy. we're talking > > about SPF as an authentication mechanism together with DKIM (not > > DMARC) as an authentication mechanism... and then using those > > authentication results in DMARC policy evaluation. > > > > But here: I've said all this before in separate places, so I'll put it > > in one place, here, one more time: > > > > Given that SPF and DKIM are both configured properly: > > 1. If SPF passes, DKIM will always pass. > > 2. If DKIM fails, SPF will always fail. > > 3. In some scenarios, DKIM will pass when SPF fails. > > > > Therefore, when everything is configured properly, SPF adds no value > > beyond what DKIM does, and DKIM does add value beyond what SPF does. > > That's why I am (and others are) arguing that we should remove SPF > > *from DMARC evaluation*. There's no argument that for now, or some, > > SPF outside of DMARC still has value. > > > > What others are arguing is that in the real world, things do get > > mis-configured, and if DKIM is misconfigured and fails when it > > shouldn't, SPF adds value by providing a working authentication. > > (And, of course, similarly the other way around, plus DKIM covers some > > cases when messages are relayed or forwarded.) That speaks for "SPF > > *or* DKIM". > > > > But "SPF *and* DKIM" -- requiring *both* to pass -- is technically > > unnecessary at best, because of (1) above: DKIM should always pass > > when SPF passes. But where the harm comes is in cases of > > mis-configuration, because now if *either* of them is misconfigured, > > the whole thing fails -- neither of them serves as a backup for the > > other; instead, the misconfiguration of either one causes > > deliverability problems. DMARC is damaged by requiring an > > authentication situation that is unnecessary when things are properly > > configured, and that is more fragile than what we've been using, more > > susceptible to configuration errors than we've seen before. > > > > And I'm afraid that people will use it preferentially, *thinking* that > > it provides better "security" -- surely, double authentication is > > better than single, no? > > > > No. > > > > Barry > > > > On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely wrote: > >> > >> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote: > >>> I'm saying I don't want "and" to be an option, because I think it's > >>> damaging to DMARC. There is no reason anyone should ever want to say > >>> that, and providing the option asks for misconfigurations because > >>> people think it's somehow "more secure". It's not more secure. It > >>> would be very bad for deliverability of legitimate mail and would > >>> provide no additional security. It would be a terrible mistake. > >> > >> > >> I've been sporting spf-all for years, and seldom experienced bounces, > >> mostly > >> due to misconfigured secondary MXes. Out of 39
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
Thank you for your analysis. However, it doesn't touch on DKIM replay. I know this topic belongs to the other list. Let me briefly recall it, if this doesn't take too many cycles from core matters: It occurs when a signed message is replayed by unauthorized hosts to recipients which were not originally addressed. So, it is one case of your 3rd proposition: In some scenarios, DKIM will pass when SPF fails. You say that it is technically unnecessary to test both because DKIM should always pass when SPF passes (1st proposition). You claim: But where the harm comes is in cases of mis-configuration, because now if *either* of them is misconfigured, the whole thing fails -- neither of them serves as a backup for the other; instead, the misconfiguration of either one causes deliverability problems. I agree. But what if SPF and DKIM are both configured properly? You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your analysis doesn't cover that case explicitly. Perhaps there are better ways to counter that specific problem, and certainly it's not what this WG is tasked to do. But, just to make the point, I think it's interesting to know. Best Ale On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote: I don't understand how most of your message fits into this discussion: you're comparing SPF's policy points with DMARC policy. we're talking about SPF as an authentication mechanism together with DKIM (not DMARC) as an authentication mechanism... and then using those authentication results in DMARC policy evaluation. But here: I've said all this before in separate places, so I'll put it in one place, here, one more time: Given that SPF and DKIM are both configured properly: 1. If SPF passes, DKIM will always pass. 2. If DKIM fails, SPF will always fail. 3. In some scenarios, DKIM will pass when SPF fails. Therefore, when everything is configured properly, SPF adds no value beyond what DKIM does, and DKIM does add value beyond what SPF does. That's why I am (and others are) arguing that we should remove SPF *from DMARC evaluation*. There's no argument that for now, or some, SPF outside of DMARC still has value. What others are arguing is that in the real world, things do get mis-configured, and if DKIM is misconfigured and fails when it shouldn't, SPF adds value by providing a working authentication. (And, of course, similarly the other way around, plus DKIM covers some cases when messages are relayed or forwarded.) That speaks for "SPF *or* DKIM". But "SPF *and* DKIM" -- requiring *both* to pass -- is technically unnecessary at best, because of (1) above: DKIM should always pass when SPF passes. But where the harm comes is in cases of mis-configuration, because now if *either* of them is misconfigured, the whole thing fails -- neither of them serves as a backup for the other; instead, the misconfiguration of either one causes deliverability problems. DMARC is damaged by requiring an authentication situation that is unnecessary when things are properly configured, and that is more fragile than what we've been using, more susceptible to configuration errors than we've seen before. And I'm afraid that people will use it preferentially, *thinking* that it provides better "security" -- surely, double authentication is better than single, no? No. Barry On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely wrote: On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote: I'm saying I don't want "and" to be an option, because I think it's damaging to DMARC. There is no reason anyone should ever want to say that, and providing the option asks for misconfigurations because people think it's somehow "more secure". It's not more secure. It would be very bad for deliverability of legitimate mail and would provide no additional security. It would be a terrible mistake. I've been sporting spf-all for years, and seldom experienced bounces, mostly due to misconfigured secondary MXes. Out of 39 domains whose posts to this list in the past year are still in my inbox, 14 have spf-all. So, while I'm not the only one, not many published -all even though it may seem to be somehow more secure. I think it can be worth to compare SPF and DMARC. Another sender policy a decade and an authentication method after. What adoption, what hype. Both policies ask receivers to reject a domain identifier in some cases. RFC 7208 explicitly suggests to consider whitelisting (Appendix D). DMARC provides for overrides but is less clear about how to handle exceptions. After SPF broke forwarding, the reaction was split between some changing identifier and turning to ~all; after DMARC broke mailing lists, between changing identifier and not altering messages. In my limited experience, the ratio seems to be higher for DMARC than SPF, but I may be wrong. In theory, domains that currently have a strict DMARC policy and spf-all, 6 of the above, should have their messages bloc
