Re: one can re-sign without a permission to re-sign header

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
>>>>> [email protected] 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.

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

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

Ale

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822