> 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.
>
> 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.
>
> 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.
> 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.
> 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
