Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC

From: Vlatko Salaj <[email-masked]>
Date: Mon, 17 Feb 2014 04:56:18 -0800 (PST)

omg, am i gonna make some ppl annoyed now... :D

i'm sure there is abundance of brain power on this list, so i'm gonna start
a new idea, something that came to me in dreams last night [no matter how
odd that may seem].

the issue is simple, but does raise some possible benefit for DMARC, in context
of verbatim forwarders.

it seems to me that SRS could be useful to DMARC well beyond the point of policy
override. it can help report original sender domain to DMARC, and thus help
SPF pass both checks - itself and its alignment.

considering SPF was changed recently, in 4408bis draft, to prefer EHLO/HELO
identity to MAIL FROM, a change that actually deals with the same problem SRS
deals with, to a degree, thus making the forwarding issue less pronounced in SPF
specs, it's no longer so important to get SRS inside that spec. the fact that
SPF is currently under review for a full fledged standard makes this even less
desirable.

on the other side, the issue of SPF alignment check, in DMARC evaluation of
a message passing through a verbatim forwarder, is still a present problem.
not only the most common forwarder deployment breaks SPF alignment, it usually
breaks DKIM signature too, by removing or changing some presigned headers -
like "sender:" header.

so, what if we were to include SRS as an additional mechanism to DMARC, one that
would help with alignment issues on messages that pass SPF checks but fail
alignment.

it would work something like this:

1. SPF verifier checks SPF on a message,

2. if SPF verification passes, make a check: is MAIL FROM an SRS type address?

3. if MAIL FROM is an SRS type address, extract original sender domain from it,
   and use it for DMARC SPF-alignment purposes.

i realize this is a long shot. but the idea is running around my head, and
i can't shake it off.

now, we need some big minds to evaluate any weaknesses in this mechanism, and
devise as simple as possible solutions to prevent abuse, if any exists. if we
were to devise such solution, this would be a complete fix for forwarders
in SPF/DMARC alignment context, possibly raising the capability bar of DMARC
and lowering its false evaluation of legitimate mail, which is, currently,
somewhat of a problem, cause it doesn't cover the wide range of email
solutions and techniques.

actually, SRS could even be extended to a fully fledged supported protocol,
a 3rd one, in DMARC terms, somewhat of a fallback case when SPF/DKIM checks
are insufficient.

as far as i can tell, the only viable abuse comes from hosts that spoof email.
however, nothing forbids them from spoofing DKIM also, thus passing DMARC, so
such hosts are already candidates to other anti-abuse algorithms. farther
more, SRS enabled DMARC could help receivers discover abusive hosts with
much greater degree of probability.

actually, to deal with this problem too, if SRS checks were to be accepted as
3rd DMARC protocol, DMARC could be changed from OR OR to AND AND evaluation
case. this would, if not close, then tighten the area for abuse even further.

i know i'm proposing a great deal of change. however, imo, this SHOULD be
welcomed, as defined in RFC 2119. :D

ur thoughts? plz, try to be open-minded as much as possible.

ps. SRS will b moving to IETF. shevek, original developer and maintainer of
SRS, has welcomed the idea. now, if only we could find time to learn how and
actually make such thing happen. :)

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 17 Feb 2014 07:31:15 -0800

On Mon, Feb 17, 2014 at 4:56 AM, Vlatko Salaj <[email-masked]> wrote:
> [Proposes SRS as an alternate authentication mechanism]. . .
> however, nothing forbids them from spoofing DKIM also, . . .

Spoofing of email is exactly the problem. Using SRS as you propose
actually would give abusers a clear path to spoof any domain that they
would like to emulate.

I don't understand your contention that anyone can spoof DKIM for a
domain not within their control. . .

--Kurt Andersen

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Feb 2014 07:44:21 -0800

On 2/17/2014 4:56 AM, Vlatko Salaj wrote:
> nothing forbids them from spoofing DKIM also,

1.  In precise technical terms, what do you mean by "spoofing DKIM"?

2.  If you are suggesting anything like a claim that DKIM's 
authentication signature can be forged, you are suggesting that its 
cryptographic mechanisms are insufficient.  If so, please explain /very/ 
carefully.  DKIM uses established crypto.

3.  If you mean that some other mechanism in a DKIM system is 
compromised, please explain that /very/ carefully.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Feb 2014 08:21:59 -0800

> SPF is currently under review for a full fledged standard makes this even

I was a participant in the SPFBIS working group, and I don't remember
anything about changing to prefer HELO/EHLO over MAIL FROM.  Can you point
me to that change?

> actually make such thing happen. :)

There's plenty of documentation online to get him started.  We can provide
links to reading materials if he needs such.

-MSK