Re: [Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
Sorry for the delay. Top level, I agree that this draft tightens up the details in a beneficial way, and the working group ought to work off the crocker version. I'm happy to also merge this version in my problem-statement draft also. My interpretation of the changes, is that the crocker draft removes one of the redundant DKIM replay definitions found in the introduction. It also tightens up the language with respect to RFC5598 and reorders the glossary section. There's a new section "Replay technical characteristics" which is gives our current understanding of what a replayed message would look like. On Thu, Mar 9, 2023 at 7:20 AM Dave Crocker wrote: > On 3/9/2023 7:04 AM, Tim Wicinski wrote: > > it would be useful to the working group if the authors > could perhaps summarize the differences between them. > > As I noted, mine is a revision of Wei's. (And I have been among the > contributors to his, for some months.) If adopted, the author list needs to > reflect that, really, it's the work of that set of authors. > > My goal was to tighten the focus, as well as to reduce the tutorial > content. It still has a fair amount of foundational introduction, since > many people don't know all the terms or use them differentially. > > For a long time, I'd thought that references to SPF should be removed, > since this is about DKIM. As the text on detection of replay developed, > I've been swayed that limited reference to SPF can be helpful. But I > removed reference to DMARC, since I think it adds nothing to detection. > I'm good removing DMARC . Glad you kept the SPF description, and put in clarifications on why SPF is important in the context of DKIM replay. > The discussion of possible prevention/mitigation is isolated to the last, > brief section. Given that the document is likely to get wide distribution, > I think it might be helpful to have a small amount of discussion that > emphasizes that this topic will not be amenable to trivial solution. > Also glad that it was kept, as I agree, I think it's important for readers to understand broad outlines of some of the existing ideas and their issues. -Wei > d/ > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.netmast:@dcrocker@mastodon.social > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
Steffen Nurpmeso wrote in <20230310002254.3yxyh%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20230309221555.or-j9%stef...@sdaoden.eu>: ... ||one could add one entry for each, with the necessity to cover all ||of these in the signature. Then receivers could check all in turn ... |Of course this is total mess as it reveals the real receivers. | |(The MUA i maintain then sends splices and sends an individual |message to each "to" when it has to encrypt. On the other hand it ... Just a thought, to avoid recalculating the entire DKIM over the entire message in the per-receiver variant. If only a marker would be included in the full DKIM signature to signal that this per-receiver DKIM variant is in use, then an additional per-receiver DKIM signature for only the single target RCPT-TO could be generated much cheaper, and injected in between a header and trailer (ie writev(2) [3]) easily, and its presence would still be verifiable signalled by the normal DKIM signature in the trailer. ... |Then again DKIM _could_ checkout DNS for some public key of |receiver domains, and then something comparable could be done. Puts a tremendous burden on the sender for possibly nothing. (That it is cacheable does not make thinks that much better.) ... Sorry. Now silent. --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
Re: [Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
Steffen Nurpmeso wrote in <20230309221555.or-j9%stef...@sdaoden.eu>: ... |one could add one entry for each, with the necessity to cover all |of these in the signature. Then receivers could check all in turn |and pick one matching. ([Of course] The values of all those Of course this is total mess as it reveals the real receivers. (The MUA i maintain then sends splices and sends an individual message to each "to" when it has to encrypt. On the other hand it is a missing feature that a single message with multiple public keys of receivers to be decrypted by all of them can be generated. Anyhow only the former "applies" here.) Then again DKIM _could_ checkout DNS for some public key of receiver domains, and then something comparable could be done. (Even in a way that does not reveal the true number of receivers i'd be hoping.) Of course the messages get larger and larger with such (even with today's small keys like ED25519, if the list of receivers is large enough), revealing something by itself. --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
Re: [Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
Dave Crocker wrote in <6a11d9c6-21aa-872d-a0ce-53420769f...@dcrocker.net>: |Name: draft-crocker-dkim-replay "mighty" surely means "might". In 2.2 "Outbound filtering" -> "Outbound filtering:". Items in 4. have no final punctuation but the last. Vice versa in first list of 5. No final punctuation in last list of page 10. I want to say that, in theory, without rereading all of DKIM and thus having a graceful understanding while i write this, in (first list of 5.) Include the SMTP RCPT-TO address in the DKIM signature: ... - If a message has more than one addressee, should the signature cover all of them, or does this require sending one message per addressee? If it covers all of them, note that they might be on different systems, so that upon arrival, the RCPT-TO list will not include all of the original addresses one could add one entry for each, with the necessity to cover all of these in the signature. Then receivers could check all in turn and pick one matching. ([Of course] The values of all those should be blake2b or a MAC not plain-text.) One could say the values are two-parted, domain name and mailbox, like that the digest/MAC of the domain name of interest could be precalculated and be found while parsing over the message via simple string comparison (instead of having one precalculated for all possible mailbox@domain to not be misunderstood). Thank you! --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
Re: [Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
On 3/9/2023 7:04 AM, Tim Wicinski wrote: it would be useful to the working group if the authors could perhaps summarize the differences between them. As I noted, mine is a revision of Wei's. (And I have been among the contributors to his, for some months.) If adopted, the author list needs to reflect that, really, it's the work of that set of authors. My goal was to tighten the focus, as well as to reduce the tutorial content. It still has a fair amount of foundational introduction, since many people don't know all the terms or use them differentially. For a long time, I'd thought that references to SPF should be removed, since this is about DKIM. As the text on detection of replay developed, I've been swayed that limited reference to SPF can be helpful. But I removed reference to DMARC, since I think it adds nothing to detection. The discussion of possible prevention/mitigation is isolated to the last, brief section. Given that the document is likely to get wide distribution, I think it might be helpful to have a small amount of discussion that emphasizes that this topic will not be amenable to trivial solution. 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] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
Dave Thanks for publishing this. So we (as the working group) have two problem statement drafts to read and consider. Wonderful! I'm going to do my reading of both (as I hope all will), but it would be useful to the working group if the authors could perhaps summarize the differences between them. thanks tim On Wed, Mar 8, 2023 at 9:25 PM Dave Crocker wrote: > FYI: > > [NOTE:] This draft is based on the Problem Statement developed by > Wei Chuan and others (including me) over some months. This > version is offered as a refinement of that draft, with a > tighter focus. Rather than being a 'separate' document, it > should be treated as an aggressive edit of that draft. It has > only my name on it, for now, since the revisions and decision > to post it were only made by me, albeit with some advice from > the WG Chairs. > > If this draft is adopted by the working group, I believe the > document's authorship needs to revert to the list currently on > Wei's version. /Dave > > > Name: draft-crocker-dkim-replay > Revision: 00 > Title: DKIM Replay: Problem Statement > Document date: 2023-03-08 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/archive/id/draft-crocker-dkim-replay-00.txt > Status: https://datatracker.ietf.org/doc/draft-crocker-dkim-replay/ > Html: https://www.ietf.org/archive/id/draft-crocker-dkim-replay-00.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-dkim-replay > > > Abstract: > DomainKeys Identified Mail (DKIM, RFC6376) permits claiming some > responsibility for a message by cryptographically associating a > domain name with the message. For data covered by the cryptographic > signature, this also enables detecting changes made during transit. > DKIM survives basic email relaying. In a Replay Attack, a recipient > of a DKIM-signed message re-posts the message to other recipients, > while retaining the original, validating signature, and thereby > leveraging the reputation of the original signer. This document > discusses the resulting damage to email delivery, interoperability, > and associated mail flows. A significant challenge to mitigating > this problem is that it is difficult for receivers to differentiate > between legitimate forwarding flows and a DKIM Replay Attack. > > > > > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.netmast:@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
[Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
FYI: [NOTE:] This draft is based on the Problem Statement developed by Wei Chuan and others (including me) over some months. This version is offered as a refinement of that draft, with a tighter focus. Rather than being a 'separate' document, it should be treated as an aggressive edit of that draft. It has only my name on it, for now, since the revisions and decision to post it were only made by me, albeit with some advice from the WG Chairs. If this draft is adopted by the working group, I believe the document's authorship needs to revert to the list currently on Wei's version. /Dave Name: draft-crocker-dkim-replay Revision: 00 Title: DKIM Replay: Problem Statement Document date: 2023-03-08 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-crocker-dkim-replay-00.txt Status: https://datatracker.ietf.org/doc/draft-crocker-dkim-replay/ Html: https://www.ietf.org/archive/id/draft-crocker-dkim-replay-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-dkim-replay Abstract: DomainKeys Identified Mail (DKIM, RFC6376) permits claiming some responsibility for a message by cryptographically associating a domain name with the message. For data covered by the cryptographic signature, this also enables detecting changes made during transit. DKIM survives basic email relaying. In a Replay Attack, a recipient of a DKIM-signed message re-posts the message to other recipients, while retaining the original, validating signature, and thereby leveraging the reputation of the original signer. This document discusses the resulting damage to email delivery, interoperability, and associated mail flows. A significant challenge to mitigating this problem is that it is difficult for receivers to differentiate between legitimate forwarding flows and a DKIM Replay Attack. -- 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
