A -03 draft is available at https://www.ietf.org/archive/id/draft-chuang-dkim-replay-problem-03.html.
On Sat, Mar 25, 2023 at 3:18 AM Laura Atkins <la...@wordtothewise.com> wrote: > > > On 24 Mar 2023, at 16:38, Murray S. Kucherawy <superu...@gmail.com> wrote: > > Informal comments only here. I know a merger with Dave's draft is in > progress, so some of these may not apply by the time you're done. > > Section 1.1: > > It feels a little presumptuous to assume any DKIM receiver has also built > out a reputation system, or has access to one. I guess it might depend on > what you consider a reputation system though; are there DNSxLs for DKIM > domains that are open to the public? I don't think SpamAssassin carries > with it a set of domains that should be dropped if they carry valid DKIM > signatures. Either way, I think the generalization is peculiar. At a > minimum, say "some systems develop reputations" etc. > > > Almost all major filtering systems (public, commercial and private) have > some sort of reputation engine in them and I’m pretty comfortable talking > about it. However, your point is well taken. I don’t think, too, that the > domain is the reputation, DKIM is really about identity. So, what if we > change the language from “reputation” to “Identity” > > Reputation is the idea that a filtering system can make an informed > judgment about whether a particular email is wanted or unwanted based on > the previous history of mail with a similar identity. What DKIM (and other > authentication methods) gives us is a durable and verifiable domain > identity to anchor the reputation. The DKIM replay attack vector is taking > advantage of that identity by, essentially, stealing the reputation of a > known good domain. > > Maybe we don’t need to mention reputation at all, even. Can we add > something like this to section 1.1 in the edited document: > > DKIM authentication allows domains to create a durable identity to attach > to email. Since its initial proposal it has been widely deployed by systems > sending and receiving email. Receiving services use the DKIM identity as > part of their inbound mail handling, and make delivery decisions based on > the DKIM domain. Email sending services sign customer email with the > customer’s own domain, but many also sign with their own domain. > Added. > > > I think I concur with the suggestion that wa should drop discussion of > ARC. This WG, or the DMARC WG, can develop an update to ARC based on the > outcome here if the community chooses to do so, but I don't think it should > be part of this WG's premise. > > > Agreed. > I believe there's some value in mentioning the susceptibility of ARC to the same type of attack. I've dropped the reference to DMARC. > > > Section 1.2: > > The opening sentence that emphasizes non-use of RFC 2119, amusingly, > forces you to include a reference to RFC 2119. I suggest instead: "This > document is not normative in any way." > > "administratively" should be "administrative functions" or similar. > ("users" and "services" are nouns, so this should be too.)S > > The "List-*" header fields are defined in RFC 4021. > > In "trace and operational headers", "headers" should be "header fields". > > Are we actually defining new Mail Handling Services here, or rather > declaring special cases of Originators and Relays? Do they become Authors > again after they've handled/filtered a message? > > Are we sure SPF and DMARC should be in scope for this work? SPF feels > irrelevant, and DMARC feels like a layer violation. If we want to do so, > we could refer the reader to the RFCs defining those protocols just to make > them aware of the bits of the ecosystem, but then I would leave them out of > the rest of the document. > > > I don’t think either should be in scope, honestly. They may end up being > part of the solution space, but the issue here is the DKIM domain. > The belief was that there's value in describing how DKIM and SPF are used together in email authentication, and in any case the mentions of SPF have been reduced. I propose the -03 draft keeping what's there now to see if it is helpful. If not, I can remove all mentions. > > Section 2: > > "headers" should be "header fields" > > "customized by" the ultimate recipient? or should that be "for"? > > Involvement of SPF here doesn't seem to be needed either. We only need to > tall the DKIM story. > I think the notion of folders also exceeds DKIM's scope. That's a > handling choice post-DKIM. It's enough to highlight that a false positive > is procured by the attacker, to the attacker's benefit. > > > +1 > > Section 3: > > Does including SPF in this part of the discussion contribute to the > problem statement or muddy it? This is about DKIM, not about spam handling > in general. > > > I think it muddies it, honestly. > > Section 3.1's "DKIM" bullet talks about signature survival, while Section > 3.2's "DKIM" bullet talks about who does the signing. This seems > dissonant, or at least makes them hard to compare and contrast since they > talk about different things. > > > Agreed. > It's been removed. > > Section 4: > > Caching known signatures, a con: adds a potentially expensive database > component to the receiving service, and will require tinkering to figure > out what cache duration is appropriate to catch replays while not also > catching legitimate mail. > > The "sign for the next hop" proposal could use a language tweak of some > kind. I can't quite put my finger on it. If it's "sign for the next hop" > at a host level, I have to know that host; today, I just sign and toss it > in the queue, and my MTA figures out which MX is going to take it, but if I > have to know which MX that is, I can't sign until connection time; > milter-based filters at least don't work that way because the integration > point doesn't allow it. If it's actually "sign for the next ADMD", that > problem goes away, but the definition of "ADMD" gets a bit muddy because > now you have to include in that definition any MX that might be providing > transparent store-and-forward. > > > Need to think a little more about this. > > Section 5 you won't need. > > Section 6 can simply say there are no security considerations for a > problem statement document, though you anticipate some interesting ones in > documents to follow. :-) > > Lastly, you can drop the "yet" from Section 7. :-) > > > Thanks. > laura > > > -MSK > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > > > -- > The Delivery Experts > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > 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