I suspect that my review of motivation-02 was missed because I sent it
in the middle if IETF week, so I’m resending it below. I see that a
couple of the comments (intended status, use of “header field”) have
been addressed elsewhere.
-Jim
Forwarded message:
From: Jim Fenton <[email protected]>
To: [email protected]
Subject: [Ietf-dkim] Review of draft-gondwana-dkim2-motivation-02
Date: Thu, 20 Mar 2025 21:21:11 +0700
Apologies for sending this so close to the WG meeting, but I seem to
work best to deadlines (and I made the WG meeting a deadline for
myself).
General comment: The draft uses the term “header” extensively,
while the correct term (in every place I have noticed) is “header
field”.
Intended status: A motivation draft would be informational, not
standards track.
Abstract: “replacing the existing email security mechanisms”:
There are lots of email security mechanisms; STARTTLS is a security
mechanism and you’re not replkacing that. I would also change
“replacing” to “improving”; whether it’s a full replacement
or something else is an implementation question.
Section 1 Paragraph 1: “Domain Key Identified Mail” ->
“DomainKeys Identified Mail”
had come from -> was signed by
source domain -> signing domain
Paragraph 2: cite RFC 6376?
Paragraph 3: “number of things”: perhaps start by listing
them?
Last paragraph: This isn’t really a motivation, and there is
disagreement as to whether there is no way to do this by extensions to
DKIM1.
Section 2.1, paragraph 1: unable to be replayed -> will not verify if
replayed
Paragraph 2: “replay to arbitrary addresses is no longer
possible”. Similar comment, and this assumes that messages with
broken signatures will not be delivered at all. Is this the intent?
Paragraph 3: “list of dkim2-unaware forwarders” This doesn’t
seem practical. It will need to list virtually every forwarder
initially.
Section 2.3: I’m wondering how sending bounces in reverse along the
same path will work for large domains. Presumably it does an MX lookup
of the sending domain? There might be incoming third-party mail
handlers, and the domain itself may have a lot of mail infrastructure.
It seems like a non-trivial problem for a large domain to associate
the bounce with the message it came from. But I suppose a large domain
has the resources to solve that problem.
Section 2.5: I don’t understand what the simplification of the
signed header [field] list accomplishes. Apparently there are
particular header fields that will be assumed to always be signed and
therefore won’t be listed. This seems like a rather unimportant
optimization that isn’t required to solve any of the problems listed
in Section 1.
Section 3.1, paragraph 2: Don’t understand what the value of the
timestamp is given the binding to the envelope-to address.
Paragraph 3: Singleton flag: interesting idea, I think I like this.
Paragraph 4: “to” or envelope-to?
Section 3.2 Paragraph 5: “bounce addresses to [be] aligned with the
most recent signature”: I don’t think this requirement was
mentioned earlier. What happens to the bounce if the bounce address
isn’t aligned?
Section 4.1: This was addressed (except for the PQC part) by the dcrup
working group not that long ago. This seems like a distraction. I
suspect that the ability to store public keys in DNS will continue to
be a challenge.
Section 7: ARC should be an informative reference since this doesn’t
depend on the ARC specification at all. The normative reference should
probably be to RFC 6376 rather than 4871.
-Jim
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
