Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023 at 9:38 PM 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? -MSK ___ 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?
On Thu, Sep 7, 2023, at 12:02 PM, Dave Crocker wrote: > On 9/2/2023 7:29 AM, Jesse Thompson wrote: >> 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. > Since a Replay Attack has the act of replaying being done by an attacker, it > would not help to have a reporting mechanism for DKIM, because the attacker > would not use it. > > If you are thinking of reporting by the later receiving platform, how would > this get used? > Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in control of the signer, as opposed to the attacker. Jesse ___ 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?
On Thu, Sep 7, 2023 at 3:15 PM Evan Burke wrote: > To be clear, for us x= was one of the most effective defenses against > large-scale replay attacks. Not perfect, obviously, but applied carefully > and in conjunction with header oversigning, it created a significantly > narrower window for attacks, and reduced the potential financial return to > attackers from replay spam. I would note that the effectiveness of x= for > reducing replay risk will likely vary considerably from signer to signer, > depending on a number of factors; we may be better positioned than many > signers in that respect. > So this is interesting, in the sense that: (1) RFC 7489 warns against using "x=" for this purpose, so if that turns out to have been the wrong advice and there's evidence to back that up, then this is an opportunity for us to say so; and (2) If such a combined (e.g., with oversigning) technique isn't terribly IPR-encumbered, you're free to put forward a description of what you did as a mitigation strategy, which this WG was hoping to produce; even if DKIM itself isn't modified, this could be an Applicability Statement. -MSK, participating ___ 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?
On Sep 7, 2023, at 6:15 PM, Evan Burke wrote: On Thu, Sep 7, 2023 at 10:17 AM Murray S. Kucherawy mailto:superu...@gmail.com>> wrote: On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker mailto:d...@dcrocker.net>> wrote: Keys cannot be rotated fast enough to be useful within the time frame that attackers work in. Key rotation works in a timeframe of days or weeks. Attackers work in the timeframe of minutes. I think we disqualified use of "x=" as a mitigation on the same basis. To be clear, for us x= was one of the most effective defenses against large-scale replay attacks. Not perfect, obviously, but applied carefully and in conjunction with header oversigning, it created a significantly narrower window for attacks, and reduced the potential financial return to attackers from replay spam. I would note that the effectiveness of x= for reducing replay risk will likely vary considerably from signer to signer, depending on a number of factors; we may be better positioned than many signers in that respect. +1 Signature expiration seemed to be a very helpful deterrent for us too. While a very limited dataset, the replay attacks that I’ve seen over the last few months mostly seem to focus on domains that don’t expire signatures. Brian ___ 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] What makes this posting different from the original posting?
On Thu, Sep 7, 2023 at 10:17 AM Murray S. Kucherawy wrote: > On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker wrote: > >> Keys cannot be rotated fast enough to be useful within the time frame >> that attackers work in. >> >> Key rotation works in a timeframe of days or weeks. Attackers work in >> the timeframe of minutes. >> > > I think we disqualified use of "x=" as a mitigation on the same basis. > To be clear, for us x= was one of the most effective defenses against large-scale replay attacks. Not perfect, obviously, but applied carefully and in conjunction with header oversigning, it created a significantly narrower window for attacks, and reduced the potential financial return to attackers from replay spam. I would note that the effectiveness of x= for reducing replay risk will likely vary considerably from signer to signer, depending on a number of factors; we may be better positioned than many signers in that respect. ___ 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?
On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker wrote: > > 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. > > Keys cannot be rotated fast enough to be useful within the time frame that > attackers work in. > > Key rotation works in a timeframe of days or weeks. Attackers work in the > timeframe of minutes. > I think we disqualified use of "x=" as a mitigation on the same basis. -MSK, participating ___ 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?
On 9/2/2023 7:29 AM, Jesse Thompson wrote: 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. Since a Replay Attack has the act of replaying being done by an attacker, it would not help to have a reporting mechanism for DKIM, because the attacker would not use it. If you are thinking of reporting by the later receiving platform, how would this get used? 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. Keys cannot be rotated fast enough to be useful within the time frame that attackers work in. Key rotation works in a timeframe of days or weeks. Attackers work in the timeframe of minutes. 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
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
Steffen Nurpmeso wrote in <20230814202928.ufult%stef...@sdaoden.eu>: ... |visibility is. (Mind you, OpenSSH is currently hardening itself |against [1], .. i persnally would simply start ticking and run for |some time after the last keypress, that needs no floating-point |arithmetic, but i am an anti-mathematician :) | | [1] https://people.eecs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf Just to add that it turns out on openssh-unix-dev@ that i would have been attackable due to > Advanced attacks where attackers run loads on onion services that influence > CPU activity and clock skew in predictable ways [2] may be possibly used to > deanonymize them. > > We would suggest drawing the padding packet intervals from some other > distribution instead of firing these off on a fixed timer. Basically, do what > kloak does but at the network layer. Yeah, making the intervals a bit uncertain seems like a reasonable idea. This gives them 10% jitter. So i had to think a bit more. (If real user key presses are attached to interval packets, i would leave it as is.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
