[Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 5, 2007, at 10:56 AM, Michael Thomas wrote:

> This is all
> really fuzzy
> though: barring S/MIME there's no guarantees about "authorship" per  
> se.

That's reasonable and I don't think it contradicts anything else  
being said here.  E.g. if I use OpenPGP signed mail because I want to  
assert that the words you read are mine.  If some intermediary (some  
of which I know about and others I have no clue about) break my  
signature, well then you can't verify that what you're reading are my  
words as I typed them.  That's exactly what should happen.

> 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.

This aligns with the way I see DKIM being useful in a mailing list  
environment.  The MLM mangles the message in ways appropriate to its  
use patterns, and it takes responsibility for the message by signing  
it with its own DKIM key.  The fact that the From header still shows  
the original author is orthogonal.

> 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.

It's also no different than transformations that can happen to email  
for any number of possible reasons.  I'm old enough to remember when  
UUCP delivery would do all kinds of transformations to emails.  What  
about other delivery mechanisms such as NNTP gating or archiving?   
Maybe your imap server does something wacky to the messages.  Those  
transformations can be perfectly legitimate, as I claim a mailing  
list's transformations are.  You as the final recipient of this  
message can only verify that the MLM has vouched for the message and  
hope that whatever gateways between the MLM and you haven't broken  
the signature.

> 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.

I go back to section 9.3 of the DKIM overview.  If you could  
implement the parsing of the DKIM headers and guarantee that any  
transformations made by Mailman would not break the signature, then  
Mailman could add its own signature and everything would be golden.   
Mailman currently cannot make such a guarantee and cannot sign  
outgoing message with its own DKIM signature, so ISTM that we're  
doing the right thing by removing the existing DKIM header.

If you (or anyone else) would like to donate some code to allow  
Mailman to do something more intelligent with the DKIM headers, for  
example by allowing us to choose points 1 or 2 from section 9.3, such  
a contribution would definitely be welcome.

> 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.

The right thing then would be for Mailman to sign the Sender header.   
Unfortunately, no MUA that I know of presents that information to a  
user, but it could still be used by a DKIM verifier.

> 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.

Well, mailing lists and even email will probably die with us  
dinosaurs anyway.  All the kids are using IM, IRC, and VOIP instead.   
But lets be honest, the DKIM specs themselves acknowledge that there  
are, at the very least, still open questions w.r.t. mailing list use  
cases.  So, trying to explore what the right thing to do work better  
than threats or hard-line positions.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcj4rnEjvBPtnXfVAQKEogQAsz0wifOZ1ocEiGX8EoJVCAsDtta21+Cr
zTX3+oihGJgiGiOnYLW7s/SgPBT3/KZugjQ0WWss4TkVss/YjAy/02mGh3i8uTkH
OKlUpnIWWmhzLPjuexA1o2RS3IChjZODSJ80fJL99jfymaR3eoDA+a4BKQIpB8z/
Q9xvLNrJuZ0=
=9teO
-----END PGP SIGNATURE-----