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

[Ned Freed <[e-mail]>]

> 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
> >>>>> [e-mail] 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