[Mailman-Developers] dkim-signature headers

[Michael Thomas]

Stephen J. Turnbull wrote:
> Michael Thomas writes:
>
>  > What it seems to me is that maybe we should look close at that
>  > behavior of when a list ought to take From: responsibility for a
>  > message ala digests. When a list completely mangles a message, is
>  > it really reasonable for it to keep acting as if it came from the
>  > original From: address? There's probably not a bright line here,
>  > but maybe we should force the issue with DKIM
>
> "Force"?!  You've got the tail wagging the dog here.
>
> From is an *author* header, not property of the MTA.  It indicates the
> *author*, not the editor or delivery agency.  If the author approves
> the message munging (and this is implicit in Internet custom or even
> the mailing lists terms of use in most cases), DKIM MUST live with it.
> So there's your bright red line.
>   
Which MTA? The submission MTA? The submission MTA can often does
have the final word on who the "author" is. In fact, the domain holder 
ultimately
decides who and who it won't delegate local parts too. This is all 
really fuzzy
though: barring S/MIME there's no guarantees about "authorship" per se. Once
it's in the hands of your MSA, it owns it. What DKIM tries to do is at least
give some guarantees at the administrative/delegation points (ie, the 
domain)
to other administrative/delegation points. It can only do this if the 
intermediate
agents in the delivery path don't destroy the signature. If something 
destroys
the signature, it's then taking responsibility for the downgrade in the 
assurance
that the signature provided. Some receivers may accept that downgrade, some
may weight it negatively, some may reject it out of hand. But ultimately 
it's
the responsibility of the signature mangler to make that tradeoff.
> I think this points in the exact opposite direction from what you
> claim: users already understand what From means in the mailing list
> context, so if From and the DKIM signature are in conflict, the latter
> SHOULD be adjusted.  Since the ML is not in possession of the relevant
> key, removal is the only option.
>   

Which makes the message look unsigned which does no good at all
and in fact manifestly causes harm.

And I really have no clue what "adjustment" you might be thinking of.
Removing things that are signed so as to make the signature useless?
Something people need to grok is that transformations of messages by
mailing lists need to be viewed as no different than transformations made
by an attacker. How does a piece of delivery machinery know whether
transformations are benign or malicious? Not very well, as it turns out.
>  > The very basic test I use is what's in the From: address. That's
>  > the thing that's pretty universally displayed and one that users
>  > are most likely to grok. Anything beyond From, and you've probably
>  > lost at least half of the user population at least.
>
> If the users don't know the difference between "From" and "Sender",
> they have little chance of using DKIM as intended *except in the case
> where From == Sender* (or they are in the same DKIM domain).  Doesn't
> this amount to saying "we don't know what DKIM BCP for mailing lists
> is---that will be determined by the ability of average users to grok
> RFC 2822 (and we believe that is quite low)".
>   

What we've been going on is that people sort understand From and that's
about it. Machine learning may be more clever in time. For mailing lists
to destroy the From signature is a problem -- compounded immensely by
arbitrarily deleting them from whence nothing can recover the signature.
>  > So the bottom line is that a valid third party signature from, say,
>  > a mailing list is not safe a priori. It requires special handling
>  > by the ultimate receiver in the form of a trust relationship with
>  > that domain which needs be done out of band. The same is not of a
>  > first party signature because you're only vouching for yourself
>  > which is already as good you trust that domain (or not).
>
> That's specious IMO.  Technically, when the mailing list signs a
> message, it's vouching for that message as the mailing list re-sent
> it.  This is exactly the same as for the originating domain.  From the
> UI standpoint, if a DKIM-enabled MUA doesn't present information
> (including their roles as originators or resenders) about *all* of the
> "DKIM senders" to the user, it is hopelessly broken for use in a
> resending environment.
>   

Spammers and bad guys can resign too. As I said, people grok From and
that's about it. If adding a third party signature causes people to give 
more
credence to the From address, then you've opened yourself up to malicious
third parties. The draft specifically states that a third party 
signature needs to
be an "acceptable" third party signature. That is, a third party you 
trust not
to screw you. How you determine that trust is not specified, but it is still
required.
> DKIM can help here.  Eg, if DKIM-enabled clients are told that they
> SHOULD recognize RFC 2369 headers and try to match the list identity
> to the DKIM signature, and DKIM is extended to provide for resenders
> (including lists that move domains---the List-ID will have a different
> domain then).
>
> Again, your argument bites the other way around.  I think it's a
> reasonable presumption that the user has *already* established the
> relevant trust relationship with the mailing list, because either the
> list is run by the user's employer (or similar), or the user opted in.
> Certainly you can presume that of any mailing list willing to
> cooperate with DKIM!
>   

Lots of MUA's don't even show Sender or Listid. And I can pretty much
guarantee that there's about zero infrastructure for whitelisting trusted
third party signatures for mailing lists right now. It's not clear that 
it will
be coming any time soon either.
> I think that all of this really points to issues that need to be
> resolved in the DKIM specification, not with mailing lists or any
> other existing infrastructure.  It's DKIM that needs to establish BCPs
> for user interface and user education, not other parts of the
> infrastructure that need to cover for DKIM's weaknesses at this point.
> Once DKIM has established its own BCPs, and technical analysis shows
> that it *requires* cooperation with other protocols to resolve
> important ambiguities, *then* it's time to ask MLMs etc to help with
> those issues.
>   

I'm afraid that intransigence from the mailing list community is likely to
really backfire. Mailing list traffic is an extremely small percentage 
of traffic,
and most admins are likely to just ignore the collateral damage if it's too
much a nuisance. Don't get me wrong: I spend far too much of my day on
mailing lists and would really like things to work out. But hard line 
positions
in the face of thorny engineering tradeoffs doesn't help.

       Mike