ietf-822
[Top] [All Lists]

Re: [ietf-822] one can re-sign without a permission to re-sign header

2014-04-26 13:07:29
On Sat 26/Apr/2014 16:24:24 +0200 Ned Freed wrote:
I know people think I'm wrong, but I think it needs to be looked at a
different way. As a recipient, I don't want 'proof' that this message
came from Alessandro, I want 'proof' that it came from the
ietf-822(_at_)ietf(_dot_)org mailing list.

I think you're right.

I concur as well.

Eh?  I agree a /receiver/ can do a better job by considering mailing
list messages as an already filtered/moderated mail stream, rather
than a collection of independent messages.  Talking domain-level
authentication, even the local part is irrelevant.  As a /recipient/,
however, the list where a message came from, ietf-822, ietf-smtp, or
whatever, is a rather circumstantial attribute of a message.  I
obviously care much more about who says what in which thread...

You're conflating completely different things here. We're talking
about assessing the validity of a message, not about the value of
the content of different valid messages.

Yes, only human recipients can distinguish between those.

And the fact is that essentially every mailing list I'm on - and
I'm on a lot of them run by a lot of different organizations - is
very good at blocking junk mail. As such, knowing that a message
came from one of the lists I'm on - even if I don't recognize the
person posting or the topic they're posting about - is more than
enough to tell me that the message isn't garbage.

Fully agreed.  My point is that all too often receiving MTAs don't
know what lists their users are on.  That has various nefarious
consequences, but maybe the one we are now talking about is relevant
enough to make a change.  All the proposed solutions require that the
originator's relay knows if the recipient of a message is a mailing list.

Which is precisely the point of having a mechanism to whitelist the
ones you are on.

SPF authentication covers most subscribers, but not those who have
their mail forwarded to different sites (unless the forwarders use
SRS).  DKIM signatures survive forwarding.

Sometimes they do, sometimes they don't. Depends on a lot of factors.

I've been using weak signatures (as on this message) for years now,
and my limited experience, based on DMARC reports after posting to one
of the few lists I'm on, seems to say they survive in many cases.
(Well, some lists strip DKIM-Signatures off.)  I'd propose an even
weaker signature: h=From:To:Date; l=0.  It should be unbreakable.

I doubt it.

Neither method is useful for DMARC because the domain being
authenticated is that of the mailing list, which is aligned with
"To:" rather than "From:".

Is it possible to introduce "To:" as a _secondary identifier_ in the
DMARC mechanism?  In that case a weak DKIM signature could be the
element which authorizes receivers to use the secondary identifier.

Maybe, but I doubt very much this would be useful. Indeed, the
reason we're in this mess is because DMARC attaches semantic
restrictions to the From: field. Attaching more semantics to more
header fields does not seem like a move in the right direction to
me.

This trick cuts two ways.  On the one hand, receivers who implement
the modified DMARC will recognize the strong (list) signature after
verifying the weak (author's domain) one.  The list can also be
authenticated by SPF in this case.  On the other hand, unmodified
receivers will just accept the weak signature if they don't have
restricting policies on signatures' strength.

I'd much rather pursue Pete's approach.

I like it too, but I haven't fully grasped it.  On the 16th he wrote:

  If the originator's site is going to allow that, you could create a
  mechanism where the originator's site gets some sort of
  cryptographic data from the mailing list site and include that in
  its signed message, such that when the eventual recipient gets the
  message, it can verify that it came from a mailing list site that
  the originator explicitly sent the mail to.
https://mailarchive.ietf.org/arch/msg/ietf/T823fjs5PWq2BjvOZ-FzZ5YMjSA

I assume the final message has a valid author's domain signature,
otherwise we need to modify DMARC.

Or override it.

The only way I see is that the
MLM, after message modification, sends the message or its hash back to
the author's site to get it signed.  That sounds too complicated, so I
must be missing something.

Perhaps it's time for a more concrete proposal to be written down.

                                Ned

_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822