Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Wei Chuang <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> On 24 Mar 2023, at 16:38, Murray S. Kucherawy <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> [e-mail]
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> _______________________________________________
> Ietf-dkim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>