On Fri, Mar 24, 2023 at 9:38 AM 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.
>
The problem statement document assumes use of DKIM and reputation systems
for delivery decisions. I've clarified the claim to take both into
account.
>
> 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.
>
The claim here is that ARC is vulnerable to replay the same way as DKIM,
noting that ARC is based on DKIM. The problem statement document doesn't
attempt to do anything further with ARC in the rest of the document.
> 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."
>
Yeah sorry about that. That's been fixed.
> "administratively" should be "administrative functions" or similar.
> ("users" and "services" are nouns, so this should be too.)
>
I've more explicitly called out that they may have different ADMDs.
> The "List-*" header fields are defined in RFC 4021.
>
Added
>
> In "trace and operational headers", "headers" should be "header fields".
>
Merged version has this.
> 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?
>
Most are already defined in RFC5598. This document goes onto refining
Boundary Filter into Inbound and Outbound Filtering Services, and
describing a ESP.
> 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.
>
SPF is noted as an aid to detection of DKIM replay. DMARC is mentioned to
explain ARC, but we can drop the mention of DMARC.
> Section 2:
>
> "headers" should be "header fields"
>
Done
>
> "customized by" the ultimate recipient? or should that be "for"?
>
That language has been dropped.
> 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.
>
> 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.
>
> 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.
>
This section has been broadly rewritten to take out the bulleted points
that were confusing.
>
> 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.
>
Added
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.
>
Yes it's apt to say sign the name of the intended next ADMD. Added
hopefully clarifying language.
>
> Section 5 you won't need.
>
Removed
>
> 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. :-)
>
Done
> Lastly, you can drop the "yet" from Section 7. :-)
>
Done
>
> -MSK
> _______________________________________________
> 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
