Subject: [ietf-822] A permission to re-sign header

From: "John Levine" <[email-masked]>
Date: 18 Apr 2014 02:19:25 -0000

As I understand it, the original sender puts a hard to forge single
use token in the message, which the forwarder can include in the
signed message.

Since I am lazy, I will reuse DKIM key records and invent a new
May-Resign header something like this:

May-Resign: f=[email-masked]; r=ietf.org; s=foo; a=rsa-sha256; \
   t=1397786669; b=hashhashhash

This is a permission to re-sign for a message From:
[email-masked], to be re-signed by a mailing list at ietf.org. The
s= and a= and t= are the same as DKIM, the b= is a signature of a hash
of the M-R header, similar to the b= signature in a DKIM-Signature.

The relay includes the M-R header in the DKIM signature.  So now
we modify DMARC to say that

IF there is a M-R header with f= that matches the From: line address,

AND the M-R header is included in a DKIM signature that is signed with
d= that matches the M-R r=

AND the M-R signature validates using the s= selector and f= domain

AND the t= isn't too old (for some meaning of too old)

THEN the message is considered to be aligned.

Is that the general idea?

You could put an M-R header on anything, but if you want to limit it
to mail to addresses that claim to be mailing lists, you could use the
same name convention as the DANE S/MIME draft, with hashed mailboxes,
e.g.:

<hash of ietf-822>._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the [email-masked] list is signed with d=ietf.org.  If a
domain contains only mailing lists, you can use a wildcard

*._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 18 Apr 2014 14:17:09 +0200

Hi John,

> AND the t= isn't too old (for some meaning of too old)

The difference from the Date: is interesting too, since the latter
field is often visible and signed.

> Is that the general idea?

Even with the local part (marissam) an M-R is not really hard to
forge, otherwise DKIM-Signature wouldn't have had to include all the
other tags.  If we worry about replay attacks, we can enhance M-R so
that it includes them too.  For example, we could make M-R exactly
like a regular DKIM-Signature, except that it would be a very very
weak one, something that the MLM won't break.  Oh, and of course we
have r=, but then its content could live in its own field.  With such
changes M-R would become quite similar to the joint signatures idea
(http://tools.ietf.org/html/draft-vesely-dkim-joint-sigs-00).

An obvious advantage of following the DKIM specs exactly is to save
developing extra code.  Another advantage is that end receivers who
ignore M-R will just see a valid author signature.  For example, this
message likely passes DMARC validation.

> *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

I'd add fields that won't be modified.  For example:

   v=MR1; d=ietf.org; h=Date:From:To:References:In-Reply-To;

Another tag could be used to say what to do with content, if it will
be fine to sign it using l=original length, or l=0.  The directive for
l= may need to differ depending on the Content-Type (text/plain or
MIME multipart).

Lazy submission servers could stick to the least common signing
directives instead of separately signing each copy of an outgoing
message, in case there are multiple mailing lists among the
recipients.  BTW, would it make sense to mandate some simple
heuristic, for example $addr=~/list/, to save DNS queries?

Ale

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2014 12:37:21 -0000

>weak one, something that the MLM won't break.

BTDT.  If we could invent a weak signature that the MLM won't break,
we wouldn't have this problem.  The M-R token is signed so it should
be impossible to forge, and we don't expect anyone to change it in
transit.

I also note that this hack, with or without Ale's changes, does
nothing to solve the send from gmail and WSJ article problems.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 18 Apr 2014 11:22:17 -0400

John,

Sounds reasonable so far, but the main issue is making the MLM honor 
such or any strict protocol logic.

What happens if the policy is strict and does not allow for 3rd party 
resigning, i.e. no M-R header is provided by the originated and 
doesn't create them as well?   Will the MLM honor the policy?

Once the HARD FAILURE handling is a acceptable consideration , then we 
can have the energy again to revisit the already discussed possible 
solutions, including looking at why YAHOO did not do what DKIM wanted 
by looking up the SDID (d= tag value) against any existing whitelist 
or trust database to lead the way, in additional as to why not using 
the AUID (i= tag) for user level unique signing.

The only real change for DMARC is to correctly lay out the 1st and 3rd 
party handling semantics given all the possible DMARC tag values between:

    p=none|quarantine|reject
    adkim==r|s
    aspf=r|s

Is this sufficient?  Why can't this M-R be described via the policy 
record?  I think it would be with the p=reject and relaxed adkim=r and 
aspf=r alignment defaults. Unless I my (quick) reading the DMARC spec 
is wrong, the YAHOO policy currently has:

    p=reject
    adkim==r  (not set, default)
    aspf=r    (not set, default)

As I understand DMARC, this means mail must be signed but it can be 
either a 1st and 3rd party signature.  This would be the same as a 
ADSP DKIM=ALL policy.  If so, maybe YAHOO is handling the logic wrong? 
  I don't see the "alignment" requirement with the implicit default 
relax alignment adkim=r, aspf=r defined for their record.  Maybe 
someone can explain where the "strict" alignment (5322.From.domain 
must equal the signer domain) is defined via yahoo's DMARC record and 
in the specification.

Anyway, I think the basic problem is to first revisit the wider, 
practical POLICY SEMANTICS for 1st party and 3rd party operations and 
make the expected protocol handling draft corrections and/or 
clarifications.  This is really about the MLM honoring STRICT 
policies, and also given the author domain the benefit of all doubt 
that their publicly exposed DMARC policy was well considered and 
published for a reason.   We should treat all domains equally with the 
protocol, including yahoo.com.

Thanks

-- 
HLS

On 4/18/2014 8:37 AM, John Levine wrote:
> _______________________________________________
> ietf-822 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-822
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 08:23:29 -0700

On Thu, Apr 17, 2014 at 7:19 PM, John Levine <[email-masked]> wrote:

> [...]

Could the same thing be accomplished by a slight adjustment to VBR,
allowing a zone to vouch for another with the specific meaning that this
means X is authorized to generate mail for Y as long as X signs it?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 18 Apr 2014 11:44:00 -0400

> means X is authorized to generate mail for Y as long as X signs it?

VBR is just a hint saying go look at a whitelist.  It has no inherent 
security and only works because it assumes the receiver already knows what 
whitelists it trusts.  (This must be obscure, too many people told us VBR 
was stupid because anyone could build a fake whitelist and point VBR 
headers at it.)

Do you mean that every DMARC publisher would have its own exception 
whitelist, and the adjustment would be to assume the whitelist is credible 
if its name matches the From: domain?  I suppose that could work, although 
expecting every domain to publish its own whitelist seems unlikely to 
scale.  A domain could indirectly use someone else's domain whitelist via 
DNAME, but urrghh.

If we expect there to be a handful of widely used DMARC exception 
whitelists, a mailing list could certainly use VBR as defined to point at 
the whitelist(s) in which its signing domain is included.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 09:16:03 -0700

> the whitelist(s) in which its signing domain is included.

Right, maybe that's what I had in mind.  It seems as though you're
essentially suggesting we need a way to confirm a relationship between X
and Y, and VBR pretty much does that.

Also, it is both the "go look at the whitelist" hint and the specification
of how the whitelist is published.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 18 Apr 2014 14:32:05 -0400

> and Y, and VBR pretty much does that.

It does, although it's a global relationship.  Pete's M-R thing is per 
message, but it's hard to think of a realistic situation with a forwarder 
that's reliable enough to allow to rewrite some messages but not others.

> of how the whitelist is published.

Yup.  No point reinventing something different.

Regards,

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 13:32:07 -0500

First of all, "permission to re-sign" seems to me to be the wrong 
semantics. This is simply "originally sent from here to there". The 
originating site (example.com) wants to say, "This message came from 
example.com and got sent to [email-masked]", in a way that 
someone who receives a message from foo.example.net can check.

> use token in the message, which the forwarder can include in the

It could be hard to forge, or it could be hard for anyone else to read 
(e.g., the token could be encrypted to the forwarder and rewritten 
usefully by the forwarder). That is, what the list gets from the 
originator does not need to be exactly what the list sends to the 
eventual recipients. But either might be a reasonable approach.

> Is that the general idea?

Yep.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 13:34:04 -0500

On 4/18/14 11:16 AM, Murray S. Kucherawy wrote:
> It seems as though you're essentially suggesting we need a way to 
> confirm a relationship between X and Y

No, I disagree. There needn't be any relationship between X and Y aside 
from "X sent a message directly to Y". The relationship is entirely 
ephemeral.

pr

---

From: "John R Levine" <[email-masked]>
Date: 18 Apr 2014 15:05:54 -0400

> First of all, "permission to re-sign" seems to me to be the wrong semantics. 
> This is simply "originally sent from here to there". The originating site 
> (example.com) wants to say, "This message came from example.com and got sent 
> to [email-masked]", in a way that someone who receives a message 
> from foo.example.net can check.

It has to be more than that, it has to say that it's OK for 
foo.example.net to pass it along in modified form.

I suppose it doesn't have to be re-signed, foo.example.net could do SPF 
path authentication, but that mixes message and path authentication in a 
way that makes me nervous.

Regards,

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Apr 2014 14:57:57 -0500

> foo.example.net to pass it along in modified form.

Why? Why isn't the fact that I sent the mail directly to this thing 
enough implicit permission for it to pass my message along in modified 
form? Is the threat model here supposed to include preventing the 
workings of evil mailing lists that I intentionally send mail to?

pr

---

From: "John R Levine" <[email-masked]>
Date: 18 Apr 2014 16:18:11 -0400

> Why? Why isn't the fact that I sent the mail directly to this thing enough 
> implicit permission for it to pass my message along in modified form? Is the 
> threat model here supposed to include preventing the workings of evil 
> mailing lists that I intentionally send mail to?

Perhaps we're using different words to say more or less the same thing. 
There seems little point to adding the token if you don't expect the 
recipient to republish it.

But I was wondering if there are things that are not mailing lists to 
which one sends mail and would be unhappy if they republished it in a way 
that shows your approval to do so.  Maybe not.  It certainly will be 
amusing if people send mail with the M-R header at the top and the 
confidential boilerplate nonsense at the bottom.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 19 Apr 2014 11:39:20 +0200

> be impossible to forge, and we don't expect anyone to change it in

I reckon M-R is equivalent to a DKIM-Signature having h=From:To; l=0;
assuming "From: [email-masked]" and "To: r=ietf.org".  Correct?

The equivalent signature is even weaker than it needs to.  IME, the
only problem is that some sites (e.g. netease) have a local policy
whereby they discard weak signatures.  (Their DMARC reports say
"DKIM-Signature could not parse or has bad tags/values".)

Ale

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Apr 2014 09:05:23 -0400

> It has to be more than that, it has to say that it's OK for foo.example.net
    > to pass it along in modified form.

Yes, in particular, it's quite likely both DKIM and S/MIME signatures will
not survive some things the mailing list might want to do, including:

1) removing html parts or other attachments
2) formatting html part to text/plain
3) formatting text/plain; format=outlook into proper format=flowed

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Apr 2014 09:07:03 -0400

John R Levine <[email-masked]> wrote:
    > But I was wondering if there are things that are not mailing lists to which
    > one sends mail and would be unhappy if they republished it in a way that
    > shows your approval to do so.  Maybe not.  It certainly will be amusing if
    > people send mail with the M-R header at the top and the confidential
    > boilerplate nonsense at the bottom.

Such as ticket/issue tracking system?
Facebook? G+?

I'm continually annoyed by both RT and facebook, because it arrives
    From: John Levine <facebook=[email-masked]>

which confuses many address book systems.

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 19 Apr 2014 11:52:41 -0400

> 3) formatting text/plain; format=outlook into proper format=flowed

We may need to consider whether this is something that we have to give
up.  I'm not sure how important it is to allow mailing lists to remove
html parts, etc.  If mailing lists need to simply reject messages that
have html parts, there are mailing lists that do that already, just as
their are mailing lists that reject messages that dont' meet other
administrative prohibition --- such as the e-mail being too large, for
example.

There are mailing lists that want to "fix" broken messages, yes, but
if we need to provide end-to-end assurance that the message really
came from the originator, disallowing this behavior so that things
like S/MIME and PGP signatures don't get broken might be an
engineering tradeoff that we might have to make.

Cheers,

					- Ted

---

From: Pete Resnick <[email-masked]>
Date: Sat, 19 Apr 2014 17:57:57 -0500

On 4/19/14 10:52 AM, Theodore Ts'o wrote:

> came from the originator...
>    

Providing end-to-end assurance that the message really came from the 
originator is not the stated goal. It would be nice if we could do that, 
but so far there are operational and deployment problems with 
accomplishing that. I've got ideas about how we might improve that 
situation, but they will take much longer to deploy than the things we 
are talking about here.

pr

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 19 Apr 2014 20:00:05 -0400

Pete Resnick wrote:
> originator is not the stated goal. It would be nice if we could do 
> that, but so far there are operational and deployment problems with 
Is that not a critical goal?  As a sender, I want to make sure that my 
message gets through intact (authentication and integrity).  As a 
recipient, I want to know who authored the message (authentication) and 
that I got what the author sent (integrity).

It strikes me that it's a secondary consideration as to whether the 
author intended to send the message to me - i.e., these cases seem 
important, but secondary:
- someone uses the list as a vector to send unwanted traffic (e.g., 
spam) - that seems to be an issue for authentication of the author, to 
the list server
- the list server sends stuff to me, even if I'm not on it (that's 
simply unsolicited email)
- a malicious actor masquerades as a list server that I'm on - that's 
about the list server authenticating itself to recipients

Ultimately, a sender cares about "protecting their name" (e.g., avoiding 
phishing attacks), and protecting the integrity of what they send.  A 
recipient wants to have some assurance that what they're reading came 
from the avowed sender, and that what you're reading is what they sent.

What that suggests to me is that:

1. The original sending system has to attach some strong cryptography to 
provide both authentication, and integrity.

2. Any intermediate system that munges pieces of the message (changing 
the From address, adding subject tags, adding message headers and 
footers) - has to ALSO add enough information that a recipient can 
recreate the original message, exactly, and validate the original 
signature.  E.g.,
- if a mailing list changes the From: address, it has to put the 
original From: address in a Original-From: header
- if a mailing list adds tags to the subject line, it has to put the 
original Subject: into an Original-Subject header
- if a mailing list adds 5 lines of header and 5 lines of footer to the 
text body, then it needs to add a header indicating as much
- with that information, software at the receiving end can recreate the 
original message, and check its authentication and integrity, and 
mistrust all of the modifications the mailing list added
- the mailing list software can additionally add signatures to 
authenticate itself and provide integrity for the things its changed/added
- of course things get a bit more complicated if MIME, or S/MIME, or 
PGP-enhanced mail, or digests, etc. are added to the mix
- and, of course, this has to be done in a standard way - otherwise 
nobody will be able to write code

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2014 01:35:00 -0000

>message gets through intact (authentication and integrity).

The copy of your message that showed up here was mutated by the
mailing list by adding a subject tag and a footer.  That is presumably
not a problem, since you've sent a bazillion messages to IETF lists.

Every previous attempt to describe mechanically what is a good
mutation vs. a bad one has been a complete failure.  The best we can
do is to try to verify that the mutations were done by someone you
trust.

Even that fails to describe the situations where a message was sent
with your approval, but not by a sender that happens to have your
signing key or use one of your SPF IP addresses.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Mon, 21 Apr 2014 19:58:21 -0700 (PDT)

> engineering tradeoff that we might have to make.

That's possible, but then you run into other problems. Take the issue
of adding a disclaimer. You can certainly do this without damaging
the S/MIME signature by converting a MIME structure of:

   multipart/signed
     text/html
     applciation/signature-whatever

to:

   multipart/mixed
     multipart/signed
       text/html
       applciation/signature-whatever
     text/plain - disclaimer

But then you have to take into account how this gets displayed, and what
it means when it is displayed.

And while you may be able to get lists to pass HTML through, reject messages
with attachments, and generally get to a place where S/MIME signatures can be
preserved, I don't think you'll be able to get rid of disclaimers.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Apr 2014 12:15:39 +0200

On Tue 22/Apr/2014 04:58:21 +0200 Ned Freed wrote:
>      application/signature-whatever
> 
> to:
> 
>    multipart/mixed
>      multipart/signed
>        text/html
>        application/signature-whatever
>      text/plain - disclaimer
> 

That alters the content-type and the very beginning of the message body.
The result may be more difficult to display/interpret than a signed
attachment.

For a related trifle, no PGP or S/MIME signatures could have pointed out
that I altered a few bits in the text quoted above, attributed to Ned.
Did I thus break authentication, non-repudiation, or integrity?

> preserved, I don't think you'll be able to get rid of disclaimers.

And subject tags too, where used.

It may seem easy to ask each ML to declare whether they tamper with the
body or the subject.  But then we have to consider possible chains
--Pete's ML assumptions, #8.  Messages containing the whole collection
of disclaimers look certainly funny.

Ale

---

From: Paul Smith <[email-masked]>
Date: Tue, 22 Apr 2014 11:38:34 +0100

> Did I thus break authentication, non-repudiation, or integrity?
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-masked] mailing list.

I have chosen to trust that mailing list. What I don't want is to 
receive messages pretending to be from that mailing list, but not really 
coming from it.

Then, because I trust that mailing list, I trust that it has done what 
it can to be sure that messages which claim to come from Alessandro 
really did.

So, I see the mailing list as being the 'final' recipient of the message 
from Alessandro. Then, the mailing list sent a new message to me, 
containing (to a reasonable degree) the content of the message which 
Alessandro sent. I did NOT receive the message from Alessandro, I 
received the 'essence' of that message, in a new message from the 
mailing list. The mailing list is not simply a forwarder/redistribution 
list, it is an entity in its own right, which receives and sends 
messages. (If you want, you could get the mailing list to include the 
original message as an attachment, so signatures etc can be validated in 
that).

Once you think of it in that way, then the problems become a lot fewer, 
IMHO. I don't really see how it can work any other way, without 
castrating the mailing list system so it just becomes a dumb 
distribution system.

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: "John Levine" <[email-masked]>
Date: 22 Apr 2014 20:24:03 -0000

>[email-masked] mailing list.

I think you're right.  I've said for years that lists should sign
their mail with their own DKIM keys, and recipients should look at
those list signatures to filter the mail.  

None of the theories about why you would care about preserving
incoming signatures have ever impressed me as having any relationship
at all to the ways people actually use mailing lists.  It's either a
vague "more secure", or a passive aggressive list manager who is
skilled enough to jump through hoops to preserve the signatures but
too much of a doofus to keep junk out of the list.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Tue, 22 Apr 2014 15:13:15 -0700 (PDT)

> I think you're right.

I concur as well.

> I've said for years that lists should sign

I'm not even sure that's necessary, but of course it can't hurt. Indeed, right
now, with the exception of IETF lists, having a signature makes the odds it's
spam more, not less, likely.

> too much of a doofus to keep junk out of the list.

Nicely put and I agree.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 22 Apr 2014 19:56:48 -0400

> spam more, not less, likely.

I think that depends on your mail stream.  Google signs all their mail 
including gmail and hosted domains, and that's a big chunk of the mail I 
get.  Yahoo signs all theirs, too.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Tue, 22 Apr 2014 17:11:58 -0700 (PDT)

> get.  Yahoo signs all theirs, too.

The overwhelming majority of list spam I get is from Google. All with
nice quthentic DKIM signatures.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Apr 2014 12:31:35 +0200

>>> [email-masked] mailing list.

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

>> I've said for years that lists should sign their mail with their
>> own DKIM keys, and recipients should look at those list
>> signatures to filter the mail.
> 
> I'm not even sure that's necessary, but of course it can't hurt.
> Indeed, right now, with the exception of IETF lists, having a
> signature makes the odds it's spam more, not less, likely.

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

>> incoming signatures have ever impressed me as having any
>> relationship at all to the ways people actually use mailing
>> lists.  It's either a vague "more secure", or a passive
>> aggressive list manager who is skilled enough to jump through
>> hoops to preserve the signatures but too much of a doofus to keep
>> junk out of the list.
> 
> Nicely put and I agree.

Again, the people who actually use mailing lists are recipients; that
is subscribers, moderators, and ML admins.  MLMs and MTAs admins may
not be the same people.  Since users subscribe to MLs unbeknownst to
their servers, I see no natural whitelist-building method that could
be formalized.  However, John said mailing lists can be declared on
DNS using a name convention like the one in the DANE S/MIME draft,
with hashed mailboxes, e.g.:

   <hash of ietf-822>._mayday.ietf.org TXT "v=MR1; d=ietf.org"

That way a server can derive that a mailing list is valid because its
users post to that address.  This method is bad for lurkers, since a
mailing list gets whitelisted only after one or more posts.

Another method to let servers know about subscriptions was named
"water tight opt-in" by David Hofstee:
http://fixforwarding.org/wiki/Water_tight_opt-in

Is it time to standardize mailing lists already?
Ale

---

From: Ned Freed <[email-masked]>
Date: Sat, 26 Apr 2014 07:24:24 -0700 (PDT)

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

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.

And not to be catty or anything, but this indicator is far more reliable than
getting a DKIM-signed message from, say, yahoo.com or aol.com. Indeed, on this
point, the SANS Digest had this to say about the situation at AOL:

  --AOL Locks Down Servers After Spam Deluge
  (April 22 & 23, 2014)
  Users have recently noticed a higher than usual volume of spam coming
  from AOL email addresses. AOL has now locked down its email servers to
  quell a spoof attack that is generating large quantities of spam. AOL
  has implemented a more stringent email validation process that instructs
  mailbox providers to reject email that appears to be associated with an
  AOL domain if the message did not originate from an AOL server. Reports
  also say that AOL Mail was breached and some accounts hijacked.
  http://www.theregister.co.uk/2014/04/23/aol_mail_locks_down_email_servers_to_deal_with_tsunami_of_spam/
  http://www.cnet.com/news/aol-imposes-stricter-email-rules-to-stem-spoofing-attack/
  http://threatpost.com/aol-email-hacked-by-spoofers-to-send-spam/105629   
  [Editor's Note (Murray): Received one from a neighbor and one from a
  family member on the same day.  I see these often enough that I have a
  standard reply.  "If you did not send the message below, your e-mail
  account may be compromised. Please change your password.  Recipients of
  your message who clicked on the embedded URL may have compromised their
  systems."]

Like Murray, I see these messages often enough that I have a standard reply to
them.

> SRS).  DKIM signatures survive forwarding.

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

> Neither method is useful

> 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. I'd much rather pursue Pete's approach.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Apr 2014 19:32:05 +0200

On Sat 26/Apr/2014 16:24:24 +0200 Ned Freed wrote:
> 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.

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

---

From: Ned Freed <[email-masked]>
Date: Sat, 26 Apr 2014 10:56:36 -0700 (PDT)

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

> weaker signature: h=From:To:Date; l=0.  It should be unbreakable.

I doubt it.

> otherwise we need to modify DMARC.

Or override it.

> The only way I see is that the

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

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Wed, 30 Apr 2014 08:54:54 -0700

>> must be missing something.

As I said to someone earlier, I take it that the author's site is 
allowing the author to have the mailing list resend a modified version 
of their message, whatever the modifications might be. So all that the 
mailing list needs is a short-lived token (probably signing the Date: 
and From: fields, maybe encrypted with the *mailing list site's* key), 
resigned by the mailing list site along with whatever the mailing list 
sees fit to sign, such that the eventual recipient can see that the 
message (a) came via the mailing list from the mailing list's site and 
(b) the mailing list got the message (some short time ago) from the 
author's site. That shouldn't require the mailing list to communicate 
with the author's site, but it might require the author's site to get 
something from the mailing list's site.

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

Ah, for a world with more time just to read these messages, let alone 
write down a proposal.

If there are others who have a handle on what I'm thinking about and 
want to work on this, I'm happy to spin up a WG to work this out. 
There's no way I'm going to be able to hold the pen on this, but I think 
I hear sufficient motivation to get this done.

pr

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Apr 2014 10:15:34 -0700

On Apr 30, 2014, at 8:54 AM, Pete Resnick <[email-masked]> wrote:

> As I said to someone earlier, I take it that the author's site is allowing the author to have the mailing list resend a modified version of their message, whatever the modifications might be. So all that the mailing list needs is a short-lived token (probably signing the Date: and From: fields, maybe encrypted with the *mailing list site's* key), resigned by the mailing list site along with whatever the mailing list sees fit to sign, such that the eventual recipient can see that the message (a) came via the mailing list from the mailing list's site and (b) the mailing list got the message (some short time ago) from the author's site. That shouldn't require the mailing list to communicate with the author's site, but it might require the author's site to get something from the mailing list's site.
> 
> Ah, for a world with more time just to read these messages, let alone write down a proposal.
> 
> If there are others who have a handle on what I'm thinking about and want to work on this, I'm happy to spin up a WG to work this out. There's no way I'm going to be able to hold the pen on this, but I think I hear sufficient motivation to get this done.

Dear Pete,

Expect a clean up of an older draft solving this problem without crypto tokens (except hash labels).  An authorization of some domain, verified in some fashion, with various constraints applied, in a way permitting retraction during abuse. This permits a chain of messages over multiple third-parties (very mailing-list friendly without tweaks to outbound servers).  It also seems however this is not the right mailing-list to discuss this alternative.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Apr 2014 14:10:48 -0400

On 4/30/2014 11:54 AM, Pete Resnick wrote:

> There's no way I'm going to be able to hold the pen on this, but I
> think I hear sufficient motivation to get this done.

If you are talking about a resigner kludge that could bypass policy, 
then I am against that.  Any solution must be permission based. I 
believe that may have been your first design assumption.

I suggest spinning up a DKIM POLICY working group to begin updating:

      RFC5016 Requirements for a DKIM Signing Practices Protocol
      http://tools.ietf.org/html/rfc5016

We need to revisit and reconfirm what are the possible policies. 
What predictably started this mess was the last minute inclusion of 
section 5.3, item 10:

    5.3.  Practice and Expectation Requirements

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

That can not be anymore. Policy must be honored if this is to work, 
but the current 'method' of choice (DMARC) needs to be fixed.  If 
DMARC is going to be selected as a DKIM policy protocol, then to help 
accelerate and lower the barrier to wide adoption, then it should 
split into two:

    DMARC-REPORTING
    DMARC-POLICY

As as right now, correct me if I am wrong, I don't think reporting is 
even an option.

Thanks

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 30 Apr 2014 11:23:21 -0700

Hi Hector,
>What predictably started this mess was the last minute inclusion of 

The steps for setting up such a working group would be:

   1. Someone writes a draft charter

   2. A group of people agree to that draft charter

   3. Contact relevant Area Director for next steps

I would not volunteer to write the draft charter as I don't want that headache.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 1 May 2014 03:29:45 -0000

>I hear sufficient motivation to get this done.

I don't think it's worth a WG, seems more like a single draft
for appsarea.  If you want I can whip one up.

Although I think it could work, it suffers from only addressing a
part, perhaps not even the major part, of the DMARC breakage.  There's
plenty of mail sources that use a From: address with the address
holder's permission, but without the message ever going anywhere near
the domain's nominal home.  The two examples I generally offer are the
WSJ's mail an article and mail account consolidation like Gmail's.
Both are useful and are designed to be hard to abuse.

R's,
John