Subject: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution")

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Apr 2015 12:06 -0400

This isn't fully fleshed out yet, so no I-D, but I've been running short of 
time, so I decided it would be better to at least get something written down.

Historical SPF discussion:

One of the use cases presented for macros in SPF records was to enable senders 
to dynamically assess information communicated via a DNS query from a 
receiver.  This is described in RFC 7208 Appendix D Section 1 (D.1).

I have seen SPF records in the wild that do variants of this, but they are 
rare.

This was seen a one potential solution to the SPF "forwarding problem".

Analogy to DMARC:

That got me thinking about the possibility of something similar for DMARC.  It 
can't be the same, since one of the indirect mail flow cases we have to address 
is mailing lists and they typically use their own mail from, so any needed 
mail from encoding would be lost.

It might be useful though to have some opt-in mechanism for DMARC senders to 
get an additional query for verification purposes.

I recall some earlier discussion about encoding information in From local 
part, but if for no other reason, automatic addition of new email addresses to 
contacts by some MUAs makes that highly problematic.

Fortunately, we don't have to be tied to either mail from or from.  We can add 
a new header field and since we aren't asking the user to interpret is, it need 
not and should not be displayed.  For the purposes of this mail, I'm calling 
it yaimfs-id. If the concept has legs, we can bike shed the name later.

Concept:

Participating senders add a new optional tag to their DMARC record, something 
like yaimfs=y and a new field in the header that is something like:

yaimfs-id: localpart@domain

Domain must be aligned with the From domain

For mail that passes DMARC, no changes are made.  If a message fails DMARC 
checks and both the DMARC record (which is already in the local cache) has 
yaimfs=y and the message has yaimfs-id is possible, then the receiver sends a 
DNS query to message-id.yamfsidlocalpart._dmarc.domain.  The sender then 
replies pass/fail/error.

I suggest message ID be included since it's supposed to be globally unique to 
reduce the risk of collision.

This idea effectively would create a new authentication protocol based on 
direct query/feedback and extend DMARC to use it.  It would be totally opt-in.

Functional assessment:

This idea has similar security properties to the proposal for adding an 
additional signature with fs=.  Since some of the indirect mail flow use cases 
are one to many transitions, a sender would have to give multple positive 
responses per message to enable mailing list (for example) use.

The security advantage is has over the fs= proposal is that the number of such 
approvals is in control of the sender.  For fs=, signature validity time is 
the only available replay constraint.  For this proposal the sender can 
determine a policy on maximum number of uses or time limit and implement it 
unilaterally.

This does not require mediators to do anything.

This does not require senders or receivers to know who are 'good' mediators.

It does require senders to maintain state on the yamfs-id tokens and pass or 
fail messages.

It does create traffic for any DMARC fail message.

It's opt-in and doesn't have a significant impact on non-implementers.

Utility assessment:

This does not require anything that's unique to a large provider.  This should 
scale reasonably well up or down (I think there's enough space in message ID 
plus yamfs-id to cover large provider needs, but it would be nice to get an 
assessment from someone at a large provider).

It requires changes from the originators and receivers, but not mediators.

I think this is useful to consider since we don't have a large/small, no 
mediator change option on the table at the moment.

Thoughts/questions (I'm sure I haven't described this well)?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Apr 2015 13:19:12 -0400

On Thursday, April 30, 2015 10:00:46 AM Kurt Andersen wrote:
> On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman <[email-masked]>
> 
> wrote:
> Interesting idea - essentially it would allow senders to provide an
> independent authorization channel for messages. What worries me, is why a
> sender would sanction a message that presumably has been sufficiently
> altered as to fail DKIM validation without knowing something about the
> content as received.
> 
> It seems somewhat like saying that if you get a check (the old-fashioned
> paper kind), that if you call me and tell me what color the paper is, then
> you can cash the check (presuming that the color is correct). I would not,
> personally, be granting any such approvals.

I think it's a bit more than that.  It's more like "Give me the serial number"  
"Oh, I just wrote a check with the number 30 seconds ago, OK"  

I agree it's not a 100% secure solution since there's a replay risk, but the 
risk is less than with the fs= proposal.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2015 18:45:25 -0000

>contacts by some MUAs makes that highly problematic.

This trick also has patent problems.

>DNS query to message-id.yamfsidlocalpart._dmarc.domain.  The sender then 

I think you will find that his has impossible scaling problems,
particularly if you care enough about security to use DNSSEC to deter
the usual poisoning attacks.  

There have been a variety of proposals over the years that publish
per-message data out of band, so the recipient can check and see if
the message is OK, and they all have the same scaling problem.

Besides, you can get the same effect by taking whatever would be in
that DNS record and putting it in the message, with a crypto signature
to prove that it's real.  The signature's validation key may come from
the DNS, but that's OK since one validation key can be shared over
many messages.  We've just reinvented DKIM, perhaps with an extra
field or two to include the yaimfs stuff.  If you're worried about
message mutations breaking the signature, don't sign the stuff that's
likely to mutate.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Apr 2015 15:27:21 -0400

On Thursday, April 30, 2015 06:45:25 PM John Levine wrote:
> >part, but if for no other reason, automatic addition of new email addresses
> >to contacts by some MUAs makes that highly problematic.
> 

Yeah.  If you want something signed, then it becomes equivalent to the fs= 
proposal.

To be effective, it would have to have something based on database queries, not 
a static zone, so I can imagine DNSSEC problems.  Is having a non-DNSSEC 
subdomain that has no real hosts in it problematic?  RBLs seem to scale 
reasonably well, although I realize per message is more of an issue than per 
sending IP.

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 30 Apr 2015 10:00:46 -0700

--Kurt