To get things going, here are a few comments on
draft-chuang-dkim-replay-problem-01:
Section 1.1:
“…list DKIM records…”: this should probably say that they sign
outgoing messages with DKIM.
“validates the message”: This sort-of implies that messages without
DKIM signatures are somehow invalid. We had used the term “email
authentication” but a more accurate term from RFC 6376 would be
“claims some responsibility for the message”.
“DKIM is one such identity”: DKIM isn’t an identity. A d= domain
in a valid signature is an identifier, however.
“Bcc header field”: There is no Bcc header field. That would
contradict the intent of bcc.
Section 1.2:
“Mailing lists…May append text to the Subject header and at the end
of the content.” Suggest describing this as modifying the Subject
header field or the content.
Section 2:
“Spammer may intentionally leave out certain headers”: RFC 6376
(section 5.4, last paragraph) recommends that signers sign all end-user
visible header fields to avoid exactly this problem. This is really
low-hanging fruit for a best practices document. I have no sympathy for
domains that don’t sign (or over-sign, if they’re not present) these
header fields and then suffer replay attacks.
Section 3.3:
“Losing control of their private key”: There shouldn’t be a single
private key in this situation; the domain should be delegating a
different selector to the outbound filtering service. If they can’t
trust the domain to manage a delegated signing key, they’re probably
not suitable to be an outgoing filtering service either. This situation
also exists for bulk senders that sign on behalf of the author domain as
well (section 3.2), but isn’t discussed there.
Section 3.4:
I would always expect an inbound filtering service to do SPF/DKIM checks
and apply an Authentication-Results header field with the result. Are
there any that don’t?
Section 3.5.1:
Why is this a subsection of Mailing list? This is an entirely different
use case.
“Updating the envelope from address (MAIL FROM)”: Not necessarily.
The classic example is if you set up a .forward file on a Unix system,
and the message is forwarded with the original MAIL FROM.
This use case has gotten a lot more complicated in recent years, with
some forwarders doing increasingly aggressive things to messages
including, in some cases, message modification.
——
While our chair has suggested we not focus on the solution space at this
point, I have a couple brief comments on section 4.
1. Envelope To address in a header field: Unless the envelope-to address
is a single address, this is a privacy violation. For the same reason,
envelope-to is omitted from Received header fields when there is more
than one recipient.
2. As an additional “con”, a DKIM signature cache would only benefit
large recipient domains, and provide no benefit to small ones.
-Jim
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
