Hi Alessandro,
On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely <ves...@tana.it> wrote:
> First, weak signatures which are not part of a chain should be ignored
> by verifiers. An authentication chain can be defined as a set of
> valid DKIM signatures and possibly an SPF authentication of delegated
> domains ("D" set), ordered such that:
>
> * the first one is an author domain signature,
> * each signature covers more header fields than the preceding one,
> * the last authentication is a full (i.e. not weak) DKIM signature, or
> an SPF "pass" authentication.
>
The first one might fail. In fact, for the use case of interest, we might
as well assume it always does.
Why the second requirement?
We already have the third requirement, minus the SPF tie-in. I'm not sure
I see the benefit of the latter, since DKIM and SPF evaluate different
things in the first place.
> That way, by adding DKIM-Delegate: and/or Resent-To: as needed, it is
> possible to have a mailing list send to another one.
>
Isn't that already possible?
> The sentence starting this point is stronger than the wording in the
> document. The latter talks about satisfying "this profile", which may
> sound like allowing those verifiers who used to validate weak
> signatures to continue their practices so long as other profiles are
> concerned. Instead, since we encourage signers to produce weak
> signatures, we ought to tell verifiers to ignore them unless they are
> part of a chain.
>
The "profile" language comes from an earlier version of the draft. I'll
clean it up in the next version.
I agree, there should be language warning about the delegation signature on
its own. However, we also have to realize that if that happens and a
receiver doesn't even know about this proposal, such text isn't going to
help any either.
> Second, Section 3 and its subsections overstate the meaning of adding
> a DKIM-Delegate: field. AIUI, it serves when the To:/Cc: fields
> contain more domains than those which are meant to be delegated.
>
That's not correct. DKIM-Delegate serves when there's a desire to delegate
to one or more of the domains listed in To:/Cc:, and not beyond that. The
"t=" tag is provided in case there's a need to further expand that list,
such as when there's a Mediator in the envelope recipients but not in the
recipient fields. (That, actually, needs to be called out in Security
Considerations; the "t=" tag reveals envelope information that might not be
intended to go anywhere.)
> Bullet 2 of Section 3.2 could characterize that better. Bullets 3 and
> 7 should not assume the field is always there. I suggest to define
> weak signatures and then characterize the method independently of the
> presence of any DKIM-Delegate: field.
>
Doesn't RFC6376 already talk at some length about what should be considered
when deciding what content should get hashed? I'm also worried about using
languages like "weak" and "strong" as it relates to signatures, because
those are pretty subjective terms.
> Third, weakly signing should be limited to messages destined to known
> mediators of trusted domains. This point is just implied in the
> document. A discussion about the correspondence between envelope
> recipients and signed destination addresses may be appropriate too.
>
By "weak" I think you're referring to the delegation signature. Yes,
that's a good suggestion, though it still imposes a requirement on the
originator to know what domains contain trusted Mediators, which is
something that has been a stalling point for things like ATPS. The Yahoo!s
of the world would have to create some process by which they either
determine what those domains are by observing their own traffic, or have a
registration process for them.
What correspondence are you referring to? DKIM has always been completely
independent of the envelope, and it should remain so.
> Fourth, a full author domain signature seems to be useless if the only
> recipient is a ML.
>
Why?
As a fifth and last point, I'd mention quotation marks (RFC 2045 token
> vs quoted-string) among the uses of z= in Section 5.1.
>
> Using z= is easier and probably more effective than trying to specify
> a list of admissible, innocuous message alterations, but looks ugly.
> Anyway, it may help having MLMs publish a how-to-sign DNS record. The
> record says what subject-tag the MLM adds, for which fields it wants
> z=, in which cases it applies which encoding transformation, and the
> like. By itself, the existence of such record will confirm that a
> given recipient expects weak signatures. Just mumbling.
>
We're specifically hoping to avoid adding still more lookups here. I'm
also not much of a fan of the proposed "z=" hacks, for the same reasons
that we abandoned that idea during the DKIM working group years. "z="
should be used to identify what got modified, but not to report a different
result.
-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
