headers
Scott Kitterman | 20 Jul 2012 19:15

RFC 6686 on Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments

Subject: [spfbis] RFC 6686 on Resolution of the Sender Policy Framework (SPF) 
and Sender ID Experiments
Date: Friday, July 20, 2012, 10:12:58 AM
From: rfc-editor <at> rfc-editor.org
To: ietf-announce <at> ietf.org, rfc-dist <at> rfc-editor.org
CC: spfbis <at> ietf.org, rfc-editor <at> rfc-editor.org

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6686

        Title:      Resolution of the Sender Policy 
                    Framework (SPF) and Sender ID Experiments 
        Author:     M. Kucherawy
        Status:     Informational
        Stream:     IETF
        Date:       July 2012
        Mailbox:    superuser <at> gmail.com
        Pages:      12
        Characters: 26421
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-spfbis-experiment-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6686.txt

In 2006, the IETF published a suite of protocol documents comprising
the Sender Policy Framework (SPF) and Sender ID: two proposed email
authentication protocols.  Both of these protocols enable one to
(Continue reading)

Permalink | Reply |
headers
Don Lee | 7 Aug 2012 18:50

DMARC?

Anyone know about this:

http://www.dmarc.org/

I've spent about 10 minutes looking into it, and it looks like a worthwhile
effort.  Other opinions?

-dgl-
Permalink | Reply |
headers
Michael Deutschmann | 11 Aug 2012 21:54

Re: DMARC?

On Tue, 7 Aug 2012, Don Lee wrote:
> Anyone know about this:
> 
> http://www.dmarc.org/

I recently perused it.  I'd have to do a more careful read of the draft
before I do anything to my DNS in response, but from what I can tell there
seems no point.  DMARC moves in precisely the wrong direction.

SPF's problem is that it false positives on all traditionally forwarded
mails.  Hence SPF can only actually halt the delivery of forgeries when
both the recipient and the putative sender are unafraid of blocked
forwards.

DKIM/ADSP's problem is that it false positives on all mailing list
traffic.  Thus it becomes crazy to publish anything other than
"dkim=unknown" when you post to mailing lists, but that means no actual
forgeries will be blocked either.

A protocol that avoids either problems could easily be developed -- it
would just have to use DKIM signatures like ADSP, but bind those
signatures to the MAIL FROM: (not header From:) like SPF.

DMARC does the opposite.  Its "SPF alignment" feature demands that MAIL
FROM: be more similar to the Header From: than a mailing list can manage.
It's the drawback of SPF and the drawback of ADSP in one package.

It would appear that since I do post to mailing lists, there is no point
in publishing DMARC (or ADSP), even though I already publish SPF and
DKIM-sign outgoing mail.
(Continue reading)

Permalink | Reply |
headers
Tim Draegen | 12 Aug 2012 17:02

Re: DMARC?

On Aug 11, 2012, at 3:54 PM, Michael Deutschmann <michael <at> talamasca.ocis.net> wrote:
> On Tue, 7 Aug 2012, Don Lee wrote:
>> Anyone know about this:
>> 
>> http://www.dmarc.org/
> 
> I recently perused it.  I'd have to do a more careful read of the draft
> before I do anything to my DNS in response, but from what I can tell there
> seems no point.  DMARC moves in precisely the wrong direction.

Cliff notes version:

- Domain Owners get new visibility into which servers on the internet are emitting email on behalf of their
domains.  Even if you never intend to put quarantine or reject policies into place, the feedback piece
alone is incredibly valuable.

- The above mentioned feedback allows complex organizations to accurately deploy SPF and DKIM across
their email streams.  Email receivers need this accuracy or else policies cannot be safely enforced.

- DMARC is aimed at email streams that are highly phished.  If you're a large financial organization and
you're under attack, DMARC is a viable way to create email streams that are resilient to phishing attacks.

- Furthermore, receivers want to move to a model of being able to  positively identify legitimate email
instead of relying on the dominant "remove bad stuff" model.  Doing so allows receivers to process and
render authenticated email in new ways.

DMARC has already shown great utility in the real world, so it's odd to read things like "DMARC moves in
precisely the wrong direction" and "I can see the rationale for ADSP and DMARC's insanity".  I recommend
reading through some of the introductory materials on dmarc.org; you'll find descriptions of the
problems DMARC is attempting to solve, along with links to even more resources.
(Continue reading)

Permalink | Reply |
headers
Michael Deutschmann | 17 Aug 2012 03:52

Re: DMARC?

On Sun, 12 Aug 2012, Tim Draegen wrote:
> DMARC has already shown great utility in the real world, so it's odd to
> read things like "DMARC moves in precisely the wrong direction" and "I can
> see the rationale for ADSP and DMARC's insanity".

I was specific as to what I consider insane - the targetting criteria.
You cannot select anything for rejection or quarantine without also
selecting all legitimate mailing list posts for the same treatment.  This
was broken in ADSP and DMARC has done nothing to fix it.

Sure, an *option* to say "No one at this domain posts to a
signature-breaking mailing list" would be useful to the rare sender
domain that can make the claim, ensuring that even phish dolled up to
look (to the filters) like something the recipient subscribed to would be
reliably blocked.

But making it a requirement ensures that most domains can never deploy a
non-null DMARC policy.  That then means there is little incentive to
deploy DMARC at the receiverside.

In contrast, the *opposite* way to "combine SPF and DKIM" would have been
quite helpful.  That is, provide a way for a domain to signal that
messages bearing its Return-path: always have a corresponding DKIM
signature, while saying nothing about messages with its From: but a third
party's Return-path:.  This would have no SPF forwarding problem and no
DKIM mailing list problem.

---- Michael Deutschmann <michael <at> talamasca.ocis.net>
(Continue reading)

Permalink | Reply |
headers
Scott Kitterman | 17 Aug 2012 08:31

Re: DMARC?

On Thursday, August 16, 2012 06:52:25 PM Michael Deutschmann wrote:
> On Sun, 12 Aug 2012, Tim Draegen wrote:
> > DMARC has already shown great utility in the real world, so it's odd to
> > read things like "DMARC moves in precisely the wrong direction" and "I can
> > see the rationale for ADSP and DMARC's insanity".
> 
> I was specific as to what I consider insane - the targetting criteria.
> You cannot select anything for rejection or quarantine without also
> selecting all legitimate mailing list posts for the same treatment.  This
> was broken in ADSP and DMARC has done nothing to fix it.
> 
> Sure, an *option* to say "No one at this domain posts to a
> signature-breaking mailing list" would be useful to the rare sender
> domain that can make the claim, ensuring that even phish dolled up to
> look (to the filters) like something the recipient subscribed to would be
> reliably blocked.
> 
> But making it a requirement ensures that most domains can never deploy a
> non-null DMARC policy.  That then means there is little incentive to
> deploy DMARC at the receiverside.
> 
> In contrast, the *opposite* way to "combine SPF and DKIM" would have been
> quite helpful.  That is, provide a way for a domain to signal that
> messages bearing its Return-path: always have a corresponding DKIM
> signature, while saying nothing about messages with its From: but a third
> party's Return-path:.  This would have no SPF forwarding problem and no
> DKIM mailing list problem.

They've got a target audience and most domains aren't in it.  I think that's 
fine as long as they are clear about it.
(Continue reading)

Permalink | Reply |
headers
Michael Deutschmann | 19 Aug 2012 00:29

Re: DMARC?

On Fri, 17 Aug 2012, Scott Kitterman wrote:
> They've got a target audience and most domains aren't in it.  I think
> that's fine as long as they are clear about it.

The problem with that is that with only phish-target domains deploying it
senderside, there is too little incentive to deploy it receiverside.

Despite the fact that DMARC should have no false positives, it seems
pointless because the expected amount of bad mail it would supress in a
year comes to about zero.  A lot of bad mail is forged, but only actual
phish is forged in the name of a phish-fearing domain.

> I've published DMARC records with a policy of none for the feedback
> reports.

Which still doesn't incentivize anyone to deploy it receiverside.

I notice some people in the DKIM camp seem to think that once their
standards advance far enough, then total receiverside deployment will just
appear by magic.  Although they apparently also think this deployment will
be done by a jerk literal genie who will build the most porous possible
configuration that still complies with the letter of the RFC.

(That's the only way to explain Douglas Otis's panic on the IETF list over
his theoretical "double From:" exploit.)

---- Michael Deutschmann <michael <at> talamasca.ocis.net>
Permalink | Reply |
headers
Bob Tinkelman | 17 Aug 2012 10:47

Re: DMARC?

> I've published DMARC records with a policy of none for the feedback reports.
> Those I think are potentially useful for everyone.  They are a great part of
> the answer to "how do I check if I got my SPF records right".  That's been a
> tough one for a long time.

Are you getting feedback reports?  If so, from whom?

It's not clear to me how to check what recipients have implemented DMARC.

- Bob
Permalink | Reply |
headers
Scott Kitterman | 18 Aug 2012 05:00

Re: DMARC?

On Friday, August 17, 2012 04:47:14 AM Bob Tinkelman wrote:
> > I've published DMARC records with a policy of none for the feedback
> > reports. Those I think are potentially useful for everyone.  They are a
> > great part of the answer to "how do I check if I got my SPF records
> > right".  That's been a tough one for a long time.
> 
> Are you getting feedback reports?  If so, from whom?
> 
> It's not clear to me how to check what recipients have implemented DMARC.

Google, Yahoo!, and AOL are the big ones.  I also get reports from Linked In, 
and 126.com/163.com (large Chinese ISP).  I understand XS4All in .nl has 
implemented, but I don't think I've gotten anything from them.

So far I only get the forensic (per message) feedback reports from 
126.com/163.com.

Scott K
Permalink | Reply |
headers
Ian Eiloart | 20 Aug 2012 13:27
Picon
Favicon
Gravatar

Re: DMARC?


On 11 Aug 2012, at 20:54, Michael Deutschmann <michael <at> talamasca.ocis.net> wrote:

>  a phisher can freely lie in
> *the address shown to an unsuspicious end user* 

Actually, there's no such thing for many recipients. Outlook 2011 for OSX (and I think 2010 and earlier for
PC), iOS Mail, Yahoo webmail and Hotmail webmail don't display sender email addresses by default. For
those webmail clients, a mouseover can reveal the From: header address, but for Outlook and iOS Mail, it's
really hard to find the address even when you know how.

For some large senders, that accounts for 70% of recipients:

http://litmus.com/blog/email-client-market-share-stats-infographic-june-2012/email-client-market-share-june-2012

--

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
Permalink | Reply |
headers
Michael Deutschmann | 21 Aug 2012 05:08

Re: DMARC?

On Mon, 20 Aug 2012, Ian Eiloart wrote:
> On 11 Aug 2012, at 20:54, Michael Deutschmann
> <michael <at> talamasca.ocis.net> wrote:
> >  a phisher can freely lie in
> > *the address shown to an unsuspicious end user*
>
> Actually, there's no such thing for many recipients. Outlook 2011 for
> OSX (and I think 2010 and earlier for PC), iOS Mail, Yahoo webmail and
> Hotmail webmail don't display sender email addresses by default. For those
> webmail clients, a mouseover can reveal the From: header address, but for
> Outlook and iOS Mail, it's really hard to find the address even when you
> know how.

So they only show the display name.

Well, then the phishers have free reign -- they can evade all technical
anti-forgery measures by simply not forging.  They just have to use their
real domain in all headers including From:

Only a display-name anti-forgery protocol can help, and that is
problematic.  To their credit, DMARC's specification draft at least
discusses it, but only to point out they have no idea how to plug the
hole, and hope someone else will.

Anyhow, it underscores my point that ADSP/DMARC's obsession with
protecting only the most visible header (From:) is insane.

SPF's forwarding problem is annoying, but only indirectly.  I've been
publishing -all since 2004 and only once encountered a domain bouncing my
mails and blaming SPF.  It only hurts because my false negative rate is
(Continue reading)

Permalink | Reply |
headers
Ian Eiloart | 21 Aug 2012 14:00
Picon
Favicon
Gravatar

Re: DMARC?


On 21 Aug 2012, at 04:08, Michael Deutschmann <michael <at> talamasca.ocis.net> wrote:

> On Mon, 20 Aug 2012, Ian Eiloart wrote:
>> On 11 Aug 2012, at 20:54, Michael Deutschmann
>> <michael <at> talamasca.ocis.net> wrote:
>>> a phisher can freely lie in
>>> *the address shown to an unsuspicious end user*
>> 
>> Actually, there's no such thing for many recipients. Outlook 2011 for
>> OSX (and I think 2010 and earlier for PC), iOS Mail, Yahoo webmail and
>> Hotmail webmail don't display sender email addresses by default. For those
>> webmail clients, a mouseover can reveal the From: header address, but for
>> Outlook and iOS Mail, it's really hard to find the address even when you
>> know how.
> 
> So they only show the display name.
> 
> Well, then the phishers have free reign -- they can evade all technical
> anti-forgery measures by simply not forging.  They just have to use their
> real domain in all headers including From:
> 
> Only a display-name anti-forgery protocol can help, and that is
> problematic.  To their credit, DMARC's specification draft at least
> discusses it, but only to point out they have no idea how to plug the
> hole, and hope someone else will.
> 
> Anyhow, it underscores my point that ADSP/DMARC's obsession with
> protecting only the most visible header (From:) is insane.
>
(Continue reading)

Permalink | Reply |
headers
Michael Deutschmann | 21 Aug 2012 23:16

Re: DMARC?

On Tue, 21 Aug 2012, Ian Eiloart wrote:
> Well, I think we need to lobby the mail client developers to show the
> email address, since it's critical. Heck, some don't even show the email
> address when you reply to the email. It's terrifying!
>
> But, the real responsibility lies with those who (should) have
> competence - the MTA operator.

The only thing the MTA could do is rewrite the From: to omit any display
names.  But that's problematic, since the DKIM signature requires that
From: be preserved byte for byte.  The MUA would be unable to verify the
signature, and just have to trust that the MTA checked it before mangling
the From:.

> And, if mailing lists break DKIM, that doesn't much matter - it's the
> list's reputation that recipients should care about. They need to add
> their own DKIM signatures.

They often do, but it doesn't help against ADSP or DMARC because the
mailing list does not own the private key needed to make a new signature
corresponding to the From:.

If ADSP/DMARC were sane like SPF, and declared a signature corresponding
to the Return-path: to be adequate, then this would work fine.

---- Michael Deutschmann <michael <at> talamasca.ocis.net>
Permalink | Reply |

Gmane