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 -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
