Hi Murray,
On Tue 10/Jun/2014 19:56:30 +0200 Murray S. Kucherawy wrote:
> 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.
Well, a chain is valid only if all of its signatures are valid.
> Why the second requirement?
The chain gets extracted from the available signatures. They need to be
ordered. In an A->B->C->D scenario, where B and C are mediators, the
receiver D has to extract A, B, C, in that order.
The set of signatures is not totally ordered, just partially. That
formulation of the second rule is handy to code a comparison function
for sorting.
> 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.
The doc says "if the receiver can otherwise determine that the message
was handled through a delegated domain". I just clarified it, adding
that only the last authentication in a chain can be handled that way.
>> 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?
No, the doc doesn't mention multiple instances of DKIM-Delegate:. BTW,
you should probably specify it has to be treated as a trace field.
>> 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.
You're right. It is both an advantage and a disadvantage. At first,
such DMARC receivers will "magically" accept mailing list traffic by
verifying only the first (weak) signature in a chain. Then they'll
learn --the hard way, if they're out of luck-- how verifications should
be carried out.
>> 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.)
The spec allows using t= to both contract or expand the delegation list
(as well as to leave it as is, redundantly). Author's domains who don't
expand that list are more respectful of that principle of header field
visibility which inspired DMARC.
In the multi-intermediary scenario above, A->B->C->D, B knows that C is
an intermediary and trusts it. Most likely, B must extend the original
delegation list. It can do so by adding a Resend-To:, a DKIM-Delegate:,
or both; neither is visible.
>> 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.
How about "partial" and "full"? The problem with "primary" and
"secondary" is that they are not so obvious.
>> 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.
Alternatively, mediators can be the first movers, flanked by their
users. I proposed an online demonstration.
> What correspondence are you referring to? DKIM has always been completely
> independent of the envelope, and it should remain so.
Formally, yes. In practice, users trust the header addresses. If a
message is authenticated, that trust ought to be warranted, up to
acceptable changes, or the authenticated entity must be willing to give
explanations in case questions arise. Isn't that what authentication is
all about?
>> Fourth, a full author domain signature seems to be useless if the only
>> recipient is a ML.
>
> Why?
If it's gonna get broken, it can only be useful for the MLM itself. Now
that you put the question, I realize that it is a clever idea for a MLM
to use it, but I think none do. MLMs who want the full author domain
signature could ask for it in their how-to-sign record (oh, well...)
>> 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.
This one would occur on sending, only when the recipient is one of those
trusted intermediaries. And can also be used to gauge how this proposal
is doing...
> 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.
Agreed. If it serves just the few cases mentioned above, case-specific
workarounds are much better.
Ale
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
