Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Doug Foster]

Better a correct answer slowly than an incorrect answer quickly.

 

For the existing PSL, it is not just the accuracy of the document itself, but 
also the accuracy of the parsing process.   Is there a well-trusted parser 
floating around?

 

DF

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Tuesday, November 24, 2020 1:19 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

 

On 11/24/2020 9:21 AM, John Levine wrote:

With the tree walk, I was thinking that if the tree walk finds a _dmarc record, 
that acts
as the organizational domain, so finance.acme.example can only allow alignment 
with itself
or its descendants.
 
This is different from the way that OD works now, but the questions are is it 
worse, and what
will break if we do it.

 

Let's consider some attributes, starting with a trivial initial set...

 

Accuracy:   How accurate is the data that gets retrieved?

Reliability:How likely is it that a query will complete successfully?

Latency:How long does it take for a query to complete?

Vulnerability:  How easily/likely is it that the service can be compromised?

Scaling:How well does it operate, at Internet scale?

 

   PSL  Tree-Walk

Accuracy:  Known problematic100%

Reliability:   High Mixed

Latency:   None Potentially high

Vulnerability: Generally none   DOS

Scaling:   Poor admin, good ops Good admin, potentially poor ops

 

d/

-- 
Dave Crocker
dcroc...@gmail.com
408.329.0791
 
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] org domain and dns-perimeter draft

[Doug Foster]

I am intrigued by Dave's document.   I have not yet read John's.   John
described this topic as a battle, so I wonder if we need a crash course in
the results of those battles before revisiting the topic.

One of the issues that did not seem sufficiently addressed was split-mode
nodes, where some descendants are public suffixes and some are
organizations.At that point, the plan becomes dependent on organizations
publishing BEGIN records. Similarly, if we ask PSL's to put a flag into
their DNS entries, we have to assume that some will comply and some will
not, and some will do so in phases.   TThe document did not provide a
mechanism for the evaluator to assess whether data is complete or missing.
I am attempting to fix those concerns.

Nonetheless, these thoughts are an abstraction inspired from Dave's
document.

Note:  I only know how to make this work if we assume a tree walk that goes
downward.

At each public suffix entry in the DNS hierarchy, we check for these flags:
 
Public suffix flag:  This is a PSL entry, it neither sends nor accepts
email.  You must look for an organization start somewhere below this point.

(Optional)  End flag:  There are no public suffixes below this point.  Every
lower entry is an organization start node.   Entries with a public suffix
flag are stating an organization preference or spoofing.

Deployment flag:   All public suffixes below this point have been tagged.   
- Once this flag is detected, if the search finds a node without the PSL
flag, it is an organization, not a public suffix 
- If this flag has not been detected and the search finds a node without the
PSL flag, use the old PSL to find the organization node.

An evaluator can walk down the tree and can always find one of these:
- an Organization entry, 
- an ambiguous ending which triggers the need to consult the old PSL, or 
- an excessive search depth which is handled as no-data-found and possible
malicious intent.


Spoofing assessment:
We cannot prevent people from mimicking a PSL flag, so we just need to limit
the risk.

As the tree is walked downward, the first entry without a PSL flag stops the
search.The PSL flag should never be checked based on a walk up the tree.
This eliminates the opportunity for mid-tree spoofing.

I see no great risk if an organization wants the top of its DNS structure to
behave like a public suffix, so I don't know that mimicking a public suffix
is a problem.   The only caveat is that we need a maximum depth to limit
malicious DNS structures intended to waste search effort by evaluators.

Doug Foster




-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Wednesday, November 18, 2020 12:55 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] org domain and dns-perimeter draft

Given the renewed discussion about organizational domain and alternative
boundaries, I'll suggest that this draft from last year might be relevant:


DNS Perimeter Overlay

<https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-01>


> Abstract
> 
>The Domain Name System (DNS) naming syntax provides no meta-data for
>indicating administrative transitions through the hierarchy.  For
>example, it does not distinguish the higher-level portions that
>operate as public registries, versus those that operate as private
>organizations.  This specification creates a basic overlay mechanism
>for defining a logical Perimeter between administrative entities
>through the naming hierarchy.  The mechanism can then be applied for
>a variety of independent administrative indications.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Doug Foster]

I was misinterpretation the language to require detection whether any host 
existed in the zone, rather than checking whether there is a host name which 
matches the domain name.  Thank you to Murray for straightening me out.

 

That aside, we still have a problem.   The specification is applying SPF-type 
logic to an address that has no necessary connection to SPF.   A typical 
advertising message, sent be a third party, will pass SPF using the third-party 
sender’s domain.The message From address becomes a label to identify the 
client organization in some manner, and possibly to identify the identity of 
the marketing campaign.  The domain name used for that purpose may not exist 
anywhere else, often does not accept replies, and may not exist as a mail 
server domain anywhere.Consequently, these may very well be unregistered 
domains, but it may be reasonable to insist that domain owners get them 
registered to avoid false positives from the test.   The least disruptive test 
will be for NS.   Anything stricter will produce false positives.

 

The logic that seems to work is:

-  Check SPF and DKIM for domain alignment.   If the DMARC criteria are 
satisfied by either method, the message domain does not need to exist, because 
it has been validated.

-  If the message does not pass DMARC alignment, then we need to look 
for a DMARC policy to see if P/SP/NP applies.  If NP applies, and NS does not 
exist, the NP policy is applied.

 

Using the example domain from the document, I am assuming that we are trying to 
block all three of these non-existent domains:

-  T4x.gov.example

-  Spammer.t4x.gov.example

-  Spammer.tax.gov.example

If the goal is only to block t4x.gov.example, then the current NP algorithm is 
slightly less problematic.

 

Doug Foster

 

 

From: Tim Wicinski [mailto:tjw.i...@gmail.com] 
Sent: Thursday, November 19, 2020 11:04 PM
To: fost...@bayviewphysicians.com
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Doug

 

In looking for domain presence most folks will look at the domain itself.  
There are a few web tools to enumerate

such as https://dnschecker.org/ 

 

Some examples

https://dnschecker.org/#MX/dmarc.org

https://dnschecker.org/#TXT/dmarc.org

https://dnschecker.org/#TXT/_dmarc.dmarc.org

 

There are unix tools - such as 'dig' - which are also quite useful.

 

hope this helps

tim

 

 

On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster 
 wrote:

Time to show my ignorance again.

 

How do I check a domain for presence or absence of A, , or MX records?

I thought most domains were protected from enumeration, so one had to know a 
name to find out if it is defined

 

DF

 

 


  _  


From: "Douglas E. Foster" 
Sent: 11/19/20 9:27 PM
To: "IETF DMARC WG" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Thank you for the pointer Eric.

 

Can someone explain why the chosen algorithm, which requires testing multiple 
conditions, is preferable to a single query for a name server record?   
Minimizing DNS traffic has been part of our recent discussion, and minimizing 
software complexity is always a good thing.

 

Can someone also explain why the DMARC appendix takes such a strong stance 
against all queries for non-existent domains, regardless of technique?  It 
seems like the philosophical incompatibilities need to be addressed before both 
documents advance.

 

DMARC is specified only as a test for the RFC5322.From domain.   
RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, 
but that is an ambiguous result, and SPF has no organization default mechanism. 
  

*   Is there data to indicate whether evaluators have found that checking 
the RFC5321.MailFrom for non-existence is useful?   
*   Suppose that the NP policy becomes generalized, and a domain has 
asserted a "must-exist" DMARC policy.   Should a non-existent subdomain used in 
the RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate 
organization, in an attempt to get whitelisted by spam filters which primarily 
evaluate the RFC5321.MailFrom address.   This attack could be paired with an 
unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise 
not generally known to be suspicious,   So my instinct is that some extension 
of DMARC to the SMTP address will be beneficial.

 

Doug Foster

 

 

 

 


  _  


From: "Chudow, Eric B CIV NSA DSAW (USA)" 
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' , 'IETF DMARC WG' 

Cc: "'dmarc-cha...@ietf.org'" 
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

 

Section 2.7. defines a non-existent domain as "a domain for which there is an 
NXDOMAIN or NODATA res

Re: [dmarc-ietf] ARC questions

[Doug Foster]

My wishlist for ARC:

 

ARC tells me that somebody changed some data, but it does not tell me which MTA 
performed the forwarding operation, added content, or performed address 
rewriting.  If we could get HELO names into the ARC data, then those names 
could be correlated with the Received header chain to make better filtering 
decisions.

 

DF   

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Monday, November 23, 2020 12:02 PM
To: Todd Herr; Joseph Brennan
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ARC questions

 

On 11/23/2020 7:38 AM, Todd Herr wrote:

On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan  wrote:

On Sat, Nov 21, 2020 at 7:14 PM John Levine  wrote:

 

This also means that ARC isn't useful if you don't have a reputation
system to tell you where the lists and other forwarders that might add
legit ARC signatures are. 

 

And if you know which hosts are legit mailing lists or forwarders, you already 
know what ARC would tell you.

 

I believe, though, that the intent of ARC is that it be scalable in ways that 
manual enumeration of known legit mailing lists and forwarders is not. 

 

"if you know which hosts are legit" buries an assumption that is problematic, 
namely that you know who handled the message.  The fack that a message purports 
to be handled by a mailing list you trust does not mean it actually was.

That's the issue that ARC resolves.

ARC (and DKIM) produce noise-free uses of identifiers.  If the authentication 
validates, the receiver knows is really was handled by who is saying it was 
handled by.  Without these, you don't.

d/

-- 

Dave Crocker
dcroc...@gmail.com
408.329.0791
 
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Doug Foster]

To return briefly to the muddy waters that I created.  John is correct that
"mail enabled" is not useful for the RFC5322.From address, and my last note
expanded on reasons why that is correct.   

However, spoofing of non-existent subdomains is a potential problem for the
RFC5321.MailFrom domain, which then becomes an attack vector for the
RFC5322.From address as well.  The problem exists because because SPF has no
organizational default.   

We need to think about intermediate nodes, non-mail leaf nodes, and
non-existent subdomains.  Assume that a spammer tries to spoof a legitimate
organization by using a non-mail  or non-existing node for both the SMTP
MailFrom address and the message From Address.   The message will be
evaluated as 
- SPF=None, 
- DomainAligned=True, and 
- (if checked by some unknown algorithm)  OrganizationReputation=good.  

Can we assume that all such messages will be blocked by all recipients?   It
seems better to have a published policy to say that it should be blocked.
Based on existing specifications, the organization has these defenses:

- All possibilities are protected if the organization DMARC sp policy is
enforceable (p<>none and pct<>0).   However, we know that this is
problematic for many organizations.

- Mail-enabled nodes should have an SPF record, so those domains will be
protected.

- Existing but non-mail domains are only protected if they have an SPF -ALL
policy.   This may be difficult and error-prone for the organization to
maintain.

Conclusions:
Assuming that many organizations are still at sp=none, we have an attack
surface from non-existent domains.  The "must exist" policy provides the
only defense for non-existent nodes when the DMARC sp policy is
non-enforcing.

Assuming that many organizations will have trouble managing deployment of
SPF -ALL universally, we have an attack surface for non-mail subdomains.
The "must be mail enabled" policy provides a simpler defense mechanism than
deploying SPF -ALL to every non-mail node.

DF




-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Chudow, Eric B CIV
NSA DSAW (USA)
Sent: Friday, November 20, 2020 6:29 AM
To: 'John Levine'; 'dmarc@ietf.org'
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
of NP

Thank you, John. I agree that it's an edge case and not worth addressing
separately. 

Eric Chudow
DoD Cybersecurity Mitigations

-Original Message-
From: John Levine 
Sent: Thursday, November 19, 2020 11:04 PM
To: dmarc@ietf.org
Cc: Chudow, Eric B CIV NSA DSAW (USA) 
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
of NP

In article
<553d43c8d961c14bb27c614ac48fc03128116...@umechpa7d.easf.csd.disa.mil> you
write:
>Section 2.7. defines a non-existent domain as "a domain for which there 
>is an NXDOMAIN or NODATA response for A, , and MX records.  This is 
>a broader definition than that in NXDOMAIN [RFC8020]." This should be
sufficient for determining that the domain is not intended to be used and
therefore could have a more stringent policy applied.
>
>The idea of looking for a "mail-enabled domain" based on if an "MX record
exists or SPF policy exists" is interesting.
>Although there may be domains that send email but not receive email and so
may not have an MX record.

These days I think you will find that if the domains in your bounce address
and your From: headers don't have an MX or A record, very few recipients
will accept your mail. This seems like an edge case. In practice I find that
the domains caught by the Org domain or I suppose PSD have A records but no
mail server because they're actually web hosts rather than mail hosts.

We have the Null MX to indicate that a domain receives no mail and SPF plain
-all to indicate that it sends no mail so I hope we don't try to reinvent
these particular wheels.

R's,
John


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] How does PSD for DMARC affect tree walk issue?

[Doug Foster]

PSD for DMARC specifies moving up one additional layer of the DNS tree to
look for the PSD policy, but it has the effect of adding DMARC policies to
all levels of participating public suffixes.How do we judge whether this
workload will be acceptable or not if widely implemented?

 

I ask because it seems to be moving us closer to the performance
implications of a scope-limited tree walk.

 

Doug Foster

 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Doug Foster]

I did not see a definition of a “non-existent domain” (the np policy).   A 
definition is needed.

 

To my thinking, the obvious rule should be to query for a NS record for the 
domain.  If the record exists, then the domain owner could create a DMARC 
record for that domain, or could create a default entry for the domain at the 
organizational level.  If no record exists, it is because the domain owner 
chose to not create one.

 

However, the DMARC Bis document conflicts strongly with this.  In section A.4, 
it suggest several ways to do a test of this type, then repudiates all of them. 
 NS lookup is not one of the mentioned options.

 

There is a possible second-level policy test for a “mail-enabled domain”.  I 
would define that test as “MX record exists or SPF policy exists”.That 
could be an additional option to NP, but should not be a replacement for it.

 

PSD for DMARC clearly intends for the NP policy to be a general solution to a 
general problem.If there are still objections to it becoming a general 
solution, this should be addressed soon.

 

Doug Foster

 

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: dmarc-cha...@ietf.org
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

 

 

All

 

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues 
raised with some of the document.   Most of them are editorial but the one big 
item was the description of the Experiment.   The chairs sat down and broke out 
the experiment section into three separate experiments, and included language 
on how to capture the data to confirm how the experiment worked.  

 

It's enough of a change that we wanted to do a second working group last call 
to make sure the working group agrees with our changes. The diff of the current 
version with the previous version is here: 

 

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08 
<https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09>
 &url2=draft-ietf-dmarc-psd-09

 

This starts a *one* week second working group last call for  
draft-ietf-dmarc-psd

Please review the changes and offer up comments to the working group.


This working group last call 20 November 2020

 

Thanks,

 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Doug Foster]

It appears that these tickets are all related to this issue:

 

#24 objection to maintaining registry for all participating public 
suffixes

#34 Define the term "Public Suffix" referencing RFC8499

#46 Separate org domain definition from core DMARC

#58 Add third lookup for public suffix domains

#59 Add third lookup for organizational home

#68 Do away with the PSL and Org Domain entirely; just walk the tree

 

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Seth Blank
Sent: Wednesday, November 11, 2020 4:34 PM
To: IETF DMARC WG
Cc: John Levine; Dave Crocker
Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On 
splitting documents and DBOUND

 

This use case is actually the intention of (the extremely poorly worded) 
https://trac.ietf.org/trac/dmarc/ticket/59

 

To the earlier conversation, this is all simplified dramatically if we define 
organizational domain (or whatever it's renamed) discovery in a separate I-D 
that DMARC just inherits...

 

 

On Wed, Nov 11, 2020 at 1:30 PM John R Levine  wrote:

On Wed, 11 Nov 2020, Dave Crocker wrote:
> Just to invoke a bit of ancient history, here, you are saying that if there 
> was the domain name:
>
>   engineering.sun.com
>
> people would be surprised that the organization domain is
>
>   oracle.com

In a DMARC context, that would be quite surprising.  I am aware that 
Oracke bought Sun quite a while ago.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc




 

-- 

Seth Blank | VP, Standards and New Technologies

e: s...@valimail.com

p: 415.273.8818 

  

 

 

This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] On splitting documents and DBOUND

[Doug Foster]

I was trying to address the tree walk objections and denial-of-service 
objections by starting at the upper end of the tree, so that an evaluator 
cannot be tricked into trying 100 possibilities for a single email message.

 

An additional protection would be to specify a few TLDs, (particularly .COM.  
.EDU, .NET, and .ORG) which will never be used for PSD DMARC entries, so an 
implementer MUST NOT look for a DMARC entry there.Those TLDS would be the 
ones at most risk of performance problems if saturated by a DMARC TXT lookups 
during tree walk.   A short don’t-look-here list is much more sustainable than 
what we have right now.

 

DF

 

From: Murray S. Kucherawy [mailto:superu...@gmail.com] 
Sent: Wednesday, November 11, 2020 12:02 PM
To: Doug Foster
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] On splitting documents and DBOUND

 

On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster 
 wrote:

Can we eliminate the PSL problem simply by adding some DNS queries?

 

Isn't there a maximum depth to the PSL, so that the evaluator can simply walk 
up the top N levels of the domain tree to find either an organizational DMARC 
entry with sp= or a PSD DMARC entry with sp=?   It looks like currently, n=4, 
because the published suffixes appear to extend to 3 levels.

 

That's been proposed, and I think it's a future topic for this WG.  (A ticket 
might be open about it already.)

 

As John just said in another thread, the DNS crowd has been largely allergic to 
the notion of a tree walk in the past, but the last time this was given serious 
consideration was when DKIM was young (2007) and it might be ripe for 
revisiting now.  It certainly would make our lives simpler.

 

-MSK

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Optional p= makes no sense

[Doug Foster]

I would be content with language that says:

If an evaluator detects a DMARC record without a policy tag, it MAY reject the 
record as invalid or it MAY treat the record as equivalent to p=none. 
Consequently, domain owners SHOULD include a p= tag, as the recipient action is 
otherwise unpredictable..

DF

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Alessandro Vesely
Sent: Monday, November 09, 2020 7:15 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Optional p= makes no sense

On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote:
> On 11/7/20 1:11 AM, Alessandro Vesely wrote:
>> On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote:
>>> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote:
>>>
 It makes no sense to allow "p=" missing.   Why would we suggest 
 that all existing implementations alter their code to tolerate 
 additional unnecessary complexity, rather than requiring domain 
 administrators to key a few more characters so that code changes will not 
 be necessary?
>>
>>
>> Are there really implementations that choke on missing p=?
>>
>> How about "v=DMARC1; p=none; p=quarantine;"?
> 
> 
> I'm pretty sure both cases would be invalid as DMARC policy records, 
> in which case they should be ignored.


I don't think so.  The current draft says:

6.  If a retrieved policy record does not contain a valid "p" tag, or
contains an "sp" tag that is not valid, then:

1.  if a "rua" tag is present and contains at least one
syntactically valid reporting URI, the Mail Receiver SHOULD
act as if a record containing a valid "v" tag and "p=none"
was retrieved, and continue processing;


> If an implementation is trying to do something with invalid records 
> like these, particularly one with multiple "p=" tags, then that would 
> be a problem.

Invalid or repeated p= tags are a problem, but possibly they don't completely 
disqualify a record.  So the question becomes "How does a missing p= tag differ 
from an invalid one?"

This is a marginal question, to define the syntax of a DMARC record as simply 
as possible (but not simpler).  I added a comment to ticket #7[*] with a 
proposed syntax.  IMHO the spec should just mention undefined behavior or some 
such, without trying to impose overly strict commitments —given that parsers 
have to deal with the possibility of non-conforming records anyway.

This question is not related with splitting policy into its own document.


Best
Ale
-- 

[*] https://trac.ietf.org/trac/dmarc/ticket/7#comment:4





























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Can we consider some process changes to speed attainment of conclusions?

[Doug Foster]

It appeared to me that adoption had the plurality of votes, by my estimate 
something like 6 to 3.   But the objections to the document were substantial 
and the proponents of proceeding said nothing during the call to indicate that 
those objections can be mitigated.

 

One of those problems is “How will the mediator know whether the target domain 
will honor the new method or not?”   

This is a trivial variant of the existing problem “How does the mediator know 
whether the target domain is enforcing DMARC against the list messages or not?”

 

Experimental status assumes that the participants are known, so it cannot 
address this fundamental issue.

 

DF

 

 

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Seth Blank
Sent: Friday, September 25, 2020 2:53 PM
To: Dotzero; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Can we consider some process changes to speed 
attainment of conclusions?

 

On Fri, Sep 25, 2020 at 11:18 AM Dotzero  wrote:

I'd also like to see calls for consensus rather than a declaration of consensus 
by the chairs based on posts from a very small minority of the members of the 
list. 

 

I'm confused. Can you point to a thread where you feel like this happened?

 

For the tickets, we've been very careful to report what we believe the 
consensus is, and to ask the list for more commentary if only a minority of 
members have spoken up. If no one objects, then we record the consensus in the 
ticket and close it out. I do not believe there have been any objections to 
consensus as recorded in the tickets. If you feel this is not the case, please 
engage in the appropriate threads.

 

The chairs have been diligently working multiple items behind the scenes so 
that we can speed up the cadence of ticket resolution. As of this week, most 
document editors are locked, and we're just finalizing the last few. As Tim 
noted, once that's done, we expect ticket cadence to pick up dramatically.

 

If there's still an issue after that point, then we'll revisit the process.

 

Seth, as Chair

 

-- 

Seth Blank | VP, Standards and New Technologies

e: s...@valimail.com

p: 415.273.8818 

  

 

 

This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC

[Doug Foster]

I cannot agree with your logic.

Assuming that you want your email gateway to accept this message, it is
because the list and the organization behind it have a positive reputation
with you.   Your trust in this message is not because you have a prior
relationship or reputation data each individual list member.   Indeed, we do
not even know the complete list of members from whom reputation data would
need to be assembled.

DMARC requires one of two actions:
- either the list confirms its identity to your email gateway by altering
the From Address, or 
- your email gateway is configured to confirm the list identity using other
parameters such as the an SPF-verified SMTP From Address.   

There is no evasion of identity.   By either method, there is formal
verification of identity where there was previously no verification.

I understand the disruption when From-Rewrite was not available and AOL was
not willing to create exceptions.   
I understand the perceived inconvenience of a rewritten From address.   
But I see the network of trust only enhanced, not diminished, by the DMARC
mechanism.

Doug Foster


-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Joseph Brennan
Sent: Wednesday, September 16, 2020 11:03 AM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] Issue submission - Mailing list security and
potential solutions using DMARC

What I mean is that mailing list software developers were obliged to find a
variety of ways to evade dmarc enforcement, for the sake of delivering
legitimate mail, and mailbox server developers learned to allow mangled mail
for the same reason. Widespread acceptance of email that evades an
authentication method diminishes its effectiveness.



On Wed, Sep 16, 2020 at 10:46 AM Dotzero  wrote:
>
>
>
> On Tue, Sep 15, 2020 at 12:02 PM Joseph Brennan 
wrote:
>>
>>
>>
>> On Tue, Sep 15, 2020 at 11:55 AM John Levine  wrote:
>>>
>>> In article 
>>> 
>>> , Joseph Brennan   wrote:
>>> >"Domain administrators must not apply dmarc authentication to 
>>> >domains from which end users send mail that may be re-sent via 
>>> >lists or automatic forwarding."  -- done. Then dmarc will be simple 
>>> >and reliable, and bank statements and similar messages are 
>>> >protected as intended. Building in a standard workaround 
>>> >significantly weakens the whole concept, doesn't it?
>>>
>>> Unfortunately, we have ample evidence that domain operators will 
>>> ignore that advice.
>>>
>>> According to someone who was in the room when Yahoo flipped the 
>>> switch, the person in charge said words to the effect that I know 
>>> this will screw up everyone's mailing lists and I don't care.
>>>
>>
>> The irony is, the result being to diminish the effectiveness of dmarc for
everybody.
>>
>>
>> Joseph Brennan
>> Lead, Email and Systems Applications
>> Columbia University Information Technology
>>
>>
>
> Can you support your assertion with data? There was zero change
post-yahoo/AOL implementation vs pre-yahoo/AOL implementation for the
organization I worked for at the time.
>
> Michael Hammer



--
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists

[Doug Foster]

SPF/DMARC are not optimal tools for detecting malice.In my experience, the 
abundance of sender configuration errors are the limiting factor.

 

However, I disagree about negative reputation.Content filtering alone is 
insufficient and even more error prone.   In the last year, I have had spam 
campaigns about LED lighting, stand-up desks, touchless thermometers, and knife 
sharpeners.  I cannot anticipate all the ways that spammers will hide their 
dirty deeds.   But I know it is spam, not merely unwanted advertising, because 
of receiving many similar messages from many different domains using many 
different servers.   Third-party RBLs help but are insufficient.   I am 
gradually building my own reputation database based on the traffic that I am 
receiving.   By blocking the problem sources, I have been able to get the spam 
problem under something approaching good control.   Content filtering is a 
useful tool for day-zero detection of a new spam source.   Once a source is 
detected, it needs to be blocked.

 

Whether a message passes SPF and DMARC criteria is part of my search critieria 
for unwanted traffic, but definitely not the only one.   As has been observed, 
actual spoofing of the From address is not a huge part of my problem at 
present.   This is largely because spammers have easy enough tools in Friendly 
Name spoofing and corporate logo misuse.   But I also attribute that low volume 
to the existence of SPF and DMARC. 

 

Doug Foster

 

 

From: Murray S. Kucherawy [mailto:superu...@gmail.com] 
Sent: Monday, September 07, 2020 4:30 PM
To: Doug Foster
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing 
lists

 

Historically, I've found that a negative source reputation is easy to dodge.  
It's trivial to come from an unknown IP address or register a new domain name, 
so an actor with a negative reputation can trivially move to a neutral one.  
Thus, a receiver/verifier seeking to make a meaningful judgement can only 
really focus on positive reputations when making meaningful filtering 
decisions; everyone else is basically the same in terms of value.

 

Another way to look at this: DKIM (and I believe SPF) only really tells you 
something interesting when it passes.  That means (for DKIM) the content was 
unmodified, and the signature is validated by a key that is verifiably present 
in some domain's DNS data.  That means the domain announcing that key 
implicitly "takes some responsibility" for the content just verified.  So the 
only variable here is the value, or reputation, of the verified name.

 

All of this is orthogonal to DMARC though, which doesn't care about reputation. 
 It only cares about alignment, and specifically alignment that is under 
complete control of the sender.

 

-MSK

 

On Sat, Sep 5, 2020 at 10:55 AM Douglas E. Foster 
 wrote:

What I am trying to accomplish is different than what can be accomplished with 
the canned-modifications indicator.To explain, I need to digress into my 
theory of operation for spam filters:

 

1) Source identification allows assignment of a Source reputation.  Source 
reputation is more important than content filtering, because hostile content 
always comes from a source that should not be trusted.   Content filtering 
always produces false positives and false negatives, and the workarounds to 
those errors are always dependent on source identification

 

2) Impersonation is always attractive to an attacker because it allows him to 
exploit the reputation of the impersonated identity.   Therefore impersonation 
is an inherently untrusted activity.

 

3) Spam filtering will assign sources to three reputation groups:   negative 
reputation (rejected), neutral reputation (acceptance depends on content 
filtering), and positive reputation (some or all content filtering bypassed.)   
SPF and DMARC are designed to block impersonation, and mailing lists look like 
impersonated traffic, so the message moves from neutral to negative reputation. 
 How to overcome that?

 

One solution is to use out-of-band information to justify overlooking the 
negative clues, then implementing local policy based on that informatoin, so 
that traffic is moved from negative reputation to positive reputation.   ARC 
and canned-modification tagging are approaches to providing in-message data 
intended to support application of that local policy.But we have found no 
way to ensure the out-of-band information flow needed to justify the local 
policy, for all of the mediators that need that status.   We have also 
identified no method for the recipient to notify the mediator that the local 
policy is established, although this could also be handed out-of-band.  
However, these techniques have the benefit of depending on the mediator and the 
recipient, and not on the sender.

 

A second solution depends on explicit sender authorization to eliminate the 

Re: [dmarc-ietf] AutoForward problems

[Doug Foster]

OAUTH vs. More careful forwarding

Pursuing both techniques makes the most sense.Some users may be
unwilling (or not allowed) to store credentials in the target server, while
being unwilling to do a manual operation to obtain their new messages.

Since OAUTH is a pull operation instead of a push, it provides several
benefits:
- Certainty that the forwarding target actually wants the message.
- Near-certainty that the message will be accepted by the client system,
since the pull bypasses the SMTP filtering process.   This includes both
sender authentication issues like DMARC as well as other content filtering
applied by the forwarding target's domain.

You point out the organizational politics will affect the process:
- For consumer-focused services like Gmail and Hotmail, the user owns the
data and has primary control over its disposition.
- For centralized organizations (most large companies), the organization
owns the data and can control its disposition.
- For decentralized organizations like your university, control is
effectively shared and negotiated.

Forwarding Control Mechanism
--
With any of the above political structures, I argue that the user should not
have sole control over the forwarding process.  

Assume that UserA@DomainA wants to forward to UserB@DomainB:

DomainA interests include:
- If DomainB objects to the messages for any reason, it may blacklist
DomainA and cause disruption to traffic other than this one user's messages.
- The forwarding action may violate company confidentiality or
organizational obligations to protect privacy of others (GDPR, PCI DSS,
HIPPA, etc.)
- DnmainA may want to assess whether the forwarding request is in good
faith, and that it is not a mule account for exfiltration of data.

DomainB and UserB@DomainB interests include:
- Does UserB actually want these messages?
- What if UserB is the victim of a typo?
- What if the auto-forward is being implemented as an attack vector on
UserB?
- What if the auto-forward is going to a non-existent account because of a
typo?

DomainA would benefit from registering the forwarding configuration with
DomainB:
- So that if DomainB has more aggressive spam filtering, the blocked traffic
will be blamed on the source and not on DomainA.
- So that DMARC verification failures can be overlooked.
- More generally, so that DomainB does  not perceive UserA@DomainA as an
open relay or other threat vector.
- If the account is overquota or closed, DomainA has an interest in
receiving notification of this event.

Consequently, I think the protocol should be:
- UserA@DomainA requests forwarding from his domain owner.
- DomainA requires a confirming email from UserB@DomainB, which should be a
trivial effort for UserA@DomainA to make happen.
- DomainA decides how much to engage the domain owner of DomainB for
purposes of registration and whitelisting.
- Assuming that no veto is received, DomainA activates the forward.

Outbound gateways can / should be used to enforce a domain's controls on the
forwarding process.

This is very different from what I have seen implemented in mail store
products.   Many systems allow any user to forward anywhere.   Some systems
allow the domain administrator to disable all forwarding from any account.
I do not think I have seen admin-controlled selective forwarding, but others
have more product experience than I do.

Doug Foster


-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Jesse Thompson
Sent: Thursday, September 03, 2020 8:42 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] AutoForward problems

On 9/2/20 6:33 AM, Douglas E. Foster wrote:
> For mailing lists, we have pushed the limits of authorization.   But there
is another class of problems where sender authorization is not feasible:  
mail which is auto-forwarded after a spam-filter has made content-altering
changes.

Yes, this is an increasing problem, as exemplified by the number of
enterprises that have started tagging subjects and bodies with [External]
warnings.  Coupled with DMARC adoption, the ability for users to
auto-forward successfully is shrinking.  

I realize that John's message in the other thread probably wasn't
referencing auto-forwarding, but I think his point dovetails to the
auto-forwarding issue:

> As always, as I hope we all remember DMARC alignment doesn't mean not 
> spam, and you still do all of the stuff you do to sort your mail.  
> This scheme depends on the forwarders you authorize being 
> well-behaved.  That's why I am concerned that senders need to be 
> selective about who they allow to forward.

I am concerned with:

a) It assumes that the domain owner has the ability and desire to authorize
every potential forwarder, even though auto-forwarding is a user-level
decision.

b) It assumes that all potential forwarders check for authorization befor

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Doug Foster]

Are the weak signatures vulnerable to a replay attack?I thought that one of 
the reasons that DKIM signatures included the whole body was to prevent the 
signature from being reused.

 

DF

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dotzero
Sent: Tuesday, August 25, 2020 1:51 PM
To: John R Levine
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list

 

 

 

On Tue, Aug 25, 2020 at 12:22 PM John R Levine  wrote:

On Tue, 25 Aug 2020, Dotzero wrote:
>> https://tools.ietf.org/html/draft-levine-dkim-conditional-00?

> Under my concept, all mail would still be signed in full. The weak
> signature would be in addition to the full signature and the intermediary
> would be expected to sign in full as well. If the original full signature
> is broken you are left with the original "weak signature" which authorizes
> the intermediary and the full signature of the intermediary.

Take another look at my old draft.  Sounds like exactly the same plan.

 

I will. 


> I would expect there to be multiple potential approaches to identifying
> acceptable intermediaries.

The harder part is to decide which intermediary gets to re-sign which 
message at the time you apply the weak signature.

 

It would have be the domain in the "To" field.  It wouldn't work with random 
unknown intermediaries. It would address the MLM issue as long as the MLM 
domain is the same as the "To" domain when the message was originally sent. It 
could also presumably work for vanity domains if they DKIM sign. It wouldn't 
work for forwards on the receiver side that the sender is unaware of.

 

Michael Hammer

 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Doug Foster]

If I followed Neil’s discussion of MajorCRM:

 

The current DMARC architecture supports authorizing a vendor to mail on behalf 
of their clients if the client includes them in their SPF policy or delegates a 
DKIM scope to them and they use it.

 

I agree that SPF is too limiting (including hard limits on complexity), and 
DKIM is too complex for an uncooperative vendor.

 

In most cases, a solution would be a controlled third-party signature 
authorization along the lines of RFC 6541.

The client would configure the authorization in his own DNS and the and the 
vendor would only need to sign with their own DKIM signature.   This is not an 
unreasonable ask for most vendors, but this particular one seems inexcusable.

 

Unfortunately, the past attempts with third-party signatures have died for lack 
of interest.  The clients of this vendor might be motivated to participate, but 
it would also require participation from the domains that receive messages from 
this vendor on behalf of the client.   Dave Crocker’s proposal has the same 
obstacles because it is a form of third-party signature authorization.

 

We would need to find a highly respected mailer who thinks they could stir up 
interest from their clients.   But major mailers will not depend on a new 
system until they are sure that it is fully deployed.   So the chicken-and-egg 
problem may doom every effort.

 

DF

 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] "Email architecture is single author"

[Doug Foster]

In brief:

My thinking is based on these foundations:
- the incoming email gateway is an AAA server which conditionally allows
anonymous logins
- The NIST framework for digital identity.  https://pages.nist.gov/800-63-3/

In that regard, digital identity is the focus, not human headcount.
"customerserv...@example.com" can be an author, even though different
individuals are responsible for different messages.

My definition of a multiple-author architecture would be one where:
- General:  The different section of the message must be tagged with the
identity of the author for that section.  
- Specific:   Since the email infrastructure is an untrusted environment,
the identities must be verifiable by some mechanism.

The chairs would probably consider this off-topic at this time, but I would
be willing to pursue a theoretical discussion at an appropriate time or
forum.


On the larger point:

You can launch an experiment with or without the paperwork blessing of IETF
Experimental status, and you may get IETF blessing despite my objections.
You can begin recruiting domain owners immediately.   So I am not your
problem.   

What you need is a really good sales pitch to convince many thousands of
domain owners, and the trade press, that this is something that they should
implement.The pitch needs to include:

- The mailing list problem is important to the email security manager.
- The mailing list behavior which creates the problem is legitimate.
(Abandon the argument that DMARC creates the problem.)
- This proposal is a sufficient solution to the problem.
- This proposal is the best solution to the problem.
- This proposal is a secure solution to the problem.

You should view me as the practice session for the sales pitch that really
matters.  

You will not get far with the sales pitch my telling your audience that they
are wrong.   

My warning is that you do not have a convincing sales pitch at this time.
I believe the sales pitch has problems in every one of these categories.

DF


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued"

[Doug Foster]

n learn that the reply made no sense because the original
did not originate from the stated From address.

Just as importantly, the assertion is hypocritical.   The end-goal of this
proposal is to allow a mailing list to set the From address to a particular
value of its choosing, because the value of the From address is perceived as
very important to their user base.   Therefore, the reader is requested to
believe that the From address is, and should be, very important to mailing
list subscribers, while it is not, and should not be, important to anyone
else.


About the Proposed Protocol:

The proposal implements an unrestricted third-party signature delegation
mechanism.

The proposal language obscures the fact that the original document's DMARC
validation occurs against the originator's domain, while the enhanced DMARC
validates only against the resender domain.  This change of reference is
necessary to achieve the intended goal for mailing lists, because the
list-altered message can only be authenticated using the mailing list
domain.   Since this arrangement is contrary to the design of DMARC or the
intent of the participating domain owner, it is not preserving the benefits
of DMARC at all.

Once a domain owner agrees to participate in this "enhanced" DMARC, anyone
can send messages "From" that domain, as long as the sender authenticates
itself using the Sender field and a corresponding DKIM signature.   These
requirements are trivial, and can be satisfied with minimal effort by any
sender, whether legitimate or malicious.The combination of this
protocol, along with the enabling DNS entry, provides a guidebook to
spammers about how to successfully spoof the participating domain. 

Consequently, this configuration produces a result which is inferior to
operating with DMARC disabled.   Without DMARC, the receiving system
observes an "Not Verified" result, which tends to encourage a rigorous risk
assessment.   With this "enhanced" DMARC, the receiving system receives an
"Authorized" result, which tends to encourage a less skeptical risk
assessment.   In reality, an authorization which is available for us by
everyone is of no value to anyone at all.

Given that the "enhanced" DMARC removes the benefit that DMARC is designed
to provide, there is no reason for a domain owner to enroll in the enhanced
process, and no reason for a message recipient to accept the recommendations
produced by the enhanced process, since the enhanced process is inferior to
no process.   

In the working group, participants indicated that prior attempts to
implement controlled third-party signature delegation have been ignored or
rejected by domain owners.   If domain owners are uninterested in controlled
third-party signature delegation, why would they be interested in one that
has no controls?


About the Intended Benefits to the Mailing List

As if all of this were not enough, this proposal will not solve the Mailing
List problem even if it is implemented widely.   The proposal does not
provide a way for mailing lists to know if the recipient system has embraced
the "enhanced" DMARC or not.   As long as the implementation question is in
doubt, the mailing list would have to proceed on the defensive assumption
that DMARCv1 is still enforced.This might produce the worst of all
possible results:   malicious sources use brute-force techniques to find and
attack those domains which accept the enhanced DMARC, while mailing lists
remain afraid to utilize the new scheme which they hoped would solve their
problem.


About Defending the Mailing List Identity

Mailing List Domains SHOULD implement DMARC to protect their subscribers.
Mailing lists such as the present one are easily spoofed, since the list is
only identified to the user by the list footer and the subject tag, both of
which are easily duplicated.Any malicious source which has this
formatting information can produce a fake posting, apply a non-DMARC value
in the From address, and send it to any known subscribers.The subscriber
will have no visible clues to indicate that it is not a legitimate post, and
the incoming email gateway would have no discernible reason to require that
the message come from an IETF server.  The spoof would succeed as long as
the malicious message was not blocked by a blacklist rule in the incoming
email gateway.

If Mailing List domains implement DMARC, replacing spoofed From addresses
with a list domain address, all submissions would become DMARC-verifiable
upon delivery, whether submitted by a DMARC-participating domain or not. 

There are several options for identifying the originator despite using the
list domain in the From address.   Some of these have been discussed in the
Working Group.


Summary

The proposal is without merit.

Doug Foster



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Doug Foster]

Hector, I do not understand this comment:

"The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party 
domains. DMARC did not address the problem and reason ADSP was abandoned. Hence 
the on-going dilemma."

Domains that participate with a mailing list have the option of including the 
ML servers in their SPF record, or delegating them a DKIM scope and key.But 
to obtain that authorization from the sending domain, someone would have to ask 
for it, and might not receive the desired answer.

The goal of this discussion is to find a way to coerce trust.   We do not lack 
ways to grant trust on request.




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Doug Foster]

Since the conflict between DMARC and Mailing Lists is related to the changes 
that Mailing List apply to a received message, it may be useful to review the 
purposes that each of those changes serve, with a goal of eliminating 
unnecessary changes.

Specifically, this list adds a footer to every message.   Is the footer a 
"trust indicator" which serves an imaginary purpose, or a necessary addition 
for other reasons?   If it is added as a trust indicator, perhaps it could be 
dropped.

I would be willing to format my submissions to IETF specifications, if it would 
protect the integrity of my signature.   But IETF has not disclosed a way for 
that to be done.   What I can determine is that the footer addition is 
currently unconditional, as evidenced by reply messages with multiple copies of 
the footer, and therefore I cannot prevent my signature from being invalidated.

DF

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Wednesday, July 22, 2020 9:24 AM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 
security considerations

On 7/21/2020 1:08 AM, Laura Atkins wrote:
> When we’re basing a protocol on “what the user sees” and “what the 
> user can trust” then I think we have to. DMARC says “users can trust 
> that mail from @domain.example is really from @domain.example” but if 
> the user never sees that, how do they know?


I think this can be connected to the query about threats that DMARC is 
intended to respond to, by virtue of suggesting clarity about /where/ 
the responding takes place.

My contention is that it takes place in a receiving filtering engine and 
does not take place at the user level.

Further, it's one more data point in that engine's analysis process, 
rather than being in any simple way definitive.

In any event, work here really should make a point of creating text that 
is clear about threats DMARC is intended to respond to, and clear about 
where such responding takes place.

To the extent any of that text makes assertions about the performance of 
end users, it needs to cite the basis for the assertions.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC threat analysis needed

[Doug Foster]

Hector, I think I am reading RFC 5016 section 5.3 differently from you.   My
paraphrase:

This SSP assertion is allowed:
"Example.com says:  Example.com messages can be considered authorized if and
only if they have a signature from our domain."

This SSP assertion is not allowed:
"Example.com says:  Example.com messages can be considered authorized if and
only if they have a signature from our domain, and DO NOT have a signature
from OtherGuy.com domain"

The second assertion is not allowed because Example.com should not be
"impugning" the validity of a signature from OtherGuy.com.   Example.com is
not empowered to be a reputation service for unrelated entities.

However, the language of this section directly supports the DMARC
implementation. 

To solve the MLM problem, you need to explain how MLMs become authorized by
the author domain to send on behalf of the author, without authorizing
spammers to send on behalf of the author.

It seems that we have an architectural problem because the current
infrastructure assumes a single author. In reality, we have multiple
situations that involve multiple authors.   For example, this message
includes your entire note, and your note includes part of Jim's note.   But
those notes no longer have valid digital signatures, so there is no proof
that I have represented you correctly, and it is technically possible for me
to rewrite your comments entirely.

A similar problem occurs if my spam filter adds content to a message as it
arrives into my domain, content that is really intended for "internal use
only".   The additions will break incoming signatures, although this is
tolerable because signatures are not checked again, as long as the message
remains internal.   But if a message is  auto-forwarded to another domain,
the additions are probably inappropriate and the message no longer passes
Sender Authentication.   I would like to be able to preserve the original
signature throughout, and remove the internal spam filter content when the
message leaves the internal domain.

Consequently, I am dreaming about an architecture that allows mediators to
add content under their own signature without voiding the signature of other
sections.   The concept is a combination of John's ARC project, which uses
nested signatures , and Murray's tagged content, which acts as a change log.
It would allow an MUA to clearly identify the content contributed by the
different authors, and it would contribute to solving the MLM problem.It
is easier to imagine how it could be used to identify additions, such as a
message footer, then to identify alternations, such as a URL rewrite.   And
the whole thing may be too complicated to implement in a way that is upward
compatible with the present architecture.   But it would be a better model
of reality.

Doug Foster



-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos
Sent: Friday, July 17, 2020 12:02 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC threat analysis needed

On 7/15/2020 8:14 PM, Jim Fenton wrote:
> Unburying this from a different thread.
>
> I'm really struggling to understand what problem(s) DMARC is trying to 
> solve. The most common answer I have heard says something about 
> "defending brand identity", which is a marketing, not a technical 
> consideration.
>
> IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the 
> technical requirements. I am NOT volunteering to do this.

Jim, if we review both RFC4686 and RC5016, I believe we might find there is
not much to be changed. However, imo, something will have to be done
regarding RFC5016 section 5.3 item:

   https://tools.ietf.org/html/rfc5016#section-5.3
   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.

This provision with strict protocol language "MUST NOT" prohibits any DKIM
Policy protocol, formally called SSP "Sender Signing Practices" 
and now today, DMARC, from impugning on 3rd party policies such as how a MLM
operator via local policy exceptions can ignorantly and blinding destroy the
integrity and resign the mail instead of just honoring it.

This language would have be updated or removed and just leave the implicit
idea that local policy always prevails in all SMTP situations.

Have a good weekend, be safe.

--
Hector Santos,
https://secure.santronics.com
https

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

[Doug Foster]

Gmail specifies quarantine.

Verizon.com, aol.com, and yahoo.com (common ownership) specify reject,
reject, and quarantine respectively.

Microsoft (live and Hotmail) specify none.

Embarqmail specifies none.

Which services did you check?


-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Benny Lyne Amorsen
Sent: Wednesday, July 15, 2020 8:17 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

Jeremy Harris  writes:

> On 15/07/2020 10:25, Benny Lyne Amorsen wrote:
>>  At the other end of the spectrum, domains which never ever 
>> participate in mailing lists or mail forwarding need some kind of 
>> "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the 
>> policy.
>
> The domain owner doesn't know.  It's his users that want to sign up
> for, and send to, MLs.   Who should be in control?

The domain owner is already (mostly) in control. They will generally have
authority over the email servers, which allows e.g. blocking all mail with a
mailing list header.

If the users do not like that policy, they will have to vote with their feet
and send mail from a different domain. I do not imagine that any of the
major "free" email domains will post "p=reject-yes-I-really-mean-it"
policies, so it is not a terrible hardship.

I checked a few of the major free email domains, they post p=none at
present. When that is the case and when they apply their own judgement to
p=reject and p=quarantine, what is the actual value of current DMARC?

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

[Doug Foster]

This is a beautiful proposal if one assumes that domain owners will want to
change.Since we do not have them well represented in this discussion, it
is a conclusion that needs to be tested.

I have pressed Dave on the issue of how good ML domains are to be
distinguished from criminal domains, a request which has not been answered.
We know that, after an edit, the only signature that can be valid is the
signature of the editor's domain.

The recipient domain can therefore be presented with two similar messages:
- a well-formed message that is signed by the good MLM domain and purports
to be on behalf of BigBank domain
- a well-formed message that is signed by a criminal domain and purports to
be on behalf of BigBank domain

Dave apparently assumes that the recipient system can reliably assign
reputation to the two messages based on the signature domain.This might
be sufficient if the recipient domain had a reliable domain reputation
system.As soon as one is invented, deployed, and universally trusted, we
can embrace his proposal.

Without another way to distinguish good MLMs from bad guys, I do not
understand how rearranging headers adds anything other than obfuscation.

DF


-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Joseph Brennan
Sent: Monday, July 13, 2020 2:28 PM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

>
>
> > 2) draft-crocker-dmarc-sender
>

This is an elegant solution. It puts the burden of change-- creating a
Sender field in all cases, and a variant DMARC record-- on the domain owner
who wants to send mail and use DMARC rules. The use of Sender complies with
RFC 5322, since it is optional whether to create Sender when it is the same
address as From.

With this implemented, developers of mailing list software can stop figuring
out which way to violate RFC 5322 in order to make mail deliverable, and
developers of clients do not have to create and display a new Author field.
Big win, for widespread acceptance, I would say.


--
Joseph Brennan
Lead, Email and Systems Applications

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

[Doug Foster]

Is not the whole point of your proposal to allow the MLM to authenticate the 
message based on the MLM domain signature alone, while presenting the document 
as originating from another domain?
That is the very behavior that DMARC is trying to prevent.

But since MLM editing is so important to you and others, it would be helpful if 
someone would document:

- what changes need to be made by an MLM?
- what objective is achieved by those changes?
- why MLM editing is the best way to achieve those objectives?
- what impact would occur if the MLM stopped editing and had to pursue those 
objectives with other measures?

We  cannot adequately address a requirement that has not been defined.

DF

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Tuesday, July 14, 2020 12:09 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

On 7/14/2020 8:39 AM, John Levine wrote:
> In article <83b1a66f-a2c4-4848-01f9-6de740a0c...@gmail.com>,
> Dave Crocker   wrote:
>> On 7/14/2020 2:52 AM, Alessandro Vesely wrote:
>>> And phishers can also send mail From: fm.bank and Sender:
>>> regleissei.icu.  To publish a DMARC policy would avail Farmers & 
>>> Merchants nothing, then.
>> If regleissei.icu publishes a DMARC record and indicates support for 
>> use of Sender:, per the proposal, please explain exactly what bad 
>> things will happen, in the case you offer.
> It makes the assessment process quadratically more complicated. Now 
> the question is both whether this from regleissei.icu, but what do we 
> know about its relationship with fm.bank.
>
> Admittedly, since a lot of MUAs display neither From nor Sender 
> address, it's not clear how much this matters.


What is, or is not, displayed is irrelevant, since that has nothing to do with 
meaningful protection.

Analysis by the filtering subsystem is quite another and more important matter.

So I'll rephrase my question:

  Please compare and contrast how analysis is done now versus how it would 
be done with this proposal, and what dangers are created or made worse as a 
result of this proposal.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

[Doug Foster]

Let's clarify the purpose of DMARC and the problem of MLM edits:

Modifying in-transit messages is a threat vector for both sender and
recipient.
The ability to constructively modify a message is also the ability to
maliciously modify a message.
And the ability to maliciously modify a message is also the ability to
create a new message which looks like a forwarded message.
In this respect, a content-editing MLM is indistinguishable from a
content-fabricating spammer.

Senders do not want to be misrepresented, and do not want their good
reputation to be exploited by those with a negative reputation.
Recipients do not want to be misled.
Consequently, sender and recipient agree to enforce DMARC policy, to prevent
this from happening.   If a message is altered in transit, or forged in its
entirety, the message will be rejected.

There are very few ways to fix this:
- MLM must gain the trust of the sender and recipient, so that it can be
distinguished by a spammer.
- Sender and recipient must be duped into accepting content that they do not
want.

RFC 7960 is worded to suggest that DMARC is to blame for the problem.   The
real problem is that MLMs have made their operating practices dependent on
weak security.   

Santa Claus could run into the same problem:   At least in the USA, he comes
down chimneys, because they are unsecured and his intentions are only good.
If criminals figure out how to enter and exit through the chimney,
homeowners will start placing locked grates on top of the chimney.  Given
the choice between "both criminals and Santa" or "neither criminals nor
Santa", most homeowners would be willing to give up Santa.  Of course, Santa
could ask for a key, which would create a key management nightmare.   Or he
could ring the doorbell, show credentials, and wait to be admitted.

The MLMs are like Santa.  They are trying to do a good thing.   But the
criminals want to use the same weaknesses that the MLMs want to use.   Given
the choice between "both" and "neither", DMARC-enforcing domains are
choosing neither.   Inducing or coercing them to use "both" mode is an
incorrect solution to the MLM problem.

DF


-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Sunday, July 12, 2020 11:20 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

FYI,

I've posted an initial draft for having DMARC use the Sender: field:

  https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

[Doug Foster]

If MLM changes are not reversible, we still have the problem of convincing the 
recipient gateway to trust the modified message.

 

At first glance, this is an internal issue between the user who created the 
subscription and his email security administrator, and that communication is 
not obviously an IETF problem.But in a large consumer-focused environment 
like Gmail, or even within a Fortune 500 enterprise, some level of automation 
may be necessary.   Additionally, the email filter MTA and the mail store are 
often separate products from separate companies, so we have an multi-vendor 
interoperability issue.  Collectively this seems to make an IETF specification 
appropriate.

 

At present, email gateways have very limited ability to distinguish between 
solicited and unsolicited mail.   Some implementations check for a match on the 
user’s contact list.   Other products check for outbound messages to the 
sender.Giving the email gateway better information about subscribed mail 
flows should improve filtering accuracy.   

 

This is the scenario in my head, a variant of something posted previously:

· User A subscribes to mailing list M.



· Mailing list M sends a message to User A with a request to ensure 
that the inbound gateway will accepts its message.   The message contains 
attachments needed to define and justify the request.I envision an XML 
attachment for use with automation, and a text file for non-automated 
environments.   An XLST file could be used to convert the XML to TXT, to 
validate that the XML attachment and the text attachment are really stating the 
same thing.   



· The configuration files provide this type of information:

o   The header fields which will uniquely identify message from this 
subscription, and the tests which can be performed to validate those headers.

o   The administrative contacts for the list.

o   Whether the list makes DKIM-invalidating changes, and why.

o   For Murray’s approach:   Whether the changes will be fully or partially 
reversible and whether it supports the tf extension.

o   For John’s approach:  Whether or not the list implements ARC.



· The email administration then reviews the request and replies to user 
and MLM in one of three ways:

o   Fully Approved - any required gateway trust changes have been implemented.  
For automated systems, the XML file is used to apply these changes.

o   Strongly rejected  - subscription is contrary to policy and should be 
cancelled; user should assume that any incoming messages will be blocked.

o   Neutral – Subscription is not rejected but no trust changes will be made.   
Any particular message may or may not be blocked.

 

Would this be more likely to succeed than the alternatives?

 

DF

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

[Doug Foster]

I like the idea of making signatures recoverable wherever possible.

 

For mailing lists, I wonder if this approach is sufficient to solve the whole 
problem.   If the MLM  transformation is for security rather than informational 
purposes, I expect that the  transformations will be (even should be) 
non-reversible. 

 

For some spam filters, it might be important.   Lots of spam filters add 
DKIM-invalidating content upon entry to the protected domain.   Many of those 
changes should be reversible.  URL rewrite is the most difficult to reverse 
using this approach.   

 

However, when the incoming and outgoing email gateways are from the same 
vendor, as I suspect is often the case, the reversal should already be feasible 
using proprietary methods.   Is any known spam filter vendor doing this type of 
reversal?

 

DF

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Sunday, July 05, 2020 5:56 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] Fwd: New Version Notification for 
draft-kucherawy-dkim-transform-01.txt

 

I decided to breathe life into this idea since it's relevant and got some 
discussion recently.  Comments welcome.

 

I'm talking to the Mailman people about the idea now; this is based on some 
things they mentioned.  I haven't managed to get the attention of Sympa or 
L-Soft yet.

 

-MSK

 

-- Forwarded message -
From: 
Date: Sun, Jul 5, 2020 at 2:46 PM
Subject: New Version Notification for draft-kucherawy-dkim-transform-01.txt
To: Murray S. Kucherawy 




A new version of I-D, draft-kucherawy-dkim-transform-01.txt
has been successfully submitted by Murray Kucherawy and posted to the
IETF repository.

Name:   draft-kucherawy-dkim-transform
Revision:   01
Title:  Recognized Transformations of Messages Bearing DomainKeys 
Identified Mail (DKIM) Signatures
Document date:  2020-07-05
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/internet-drafts/draft-kucherawy-dkim-transform-01.txt
Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/
Htmlized:   https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-transform
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-transform-01

Abstract:
   DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a
   mail operator can affix a signature to a message that validates at
   the level of the signer's domain name.  It specified two possible
   ways of converting the message body to a canonical form, one
   intolerant of changes and the other tolerant of simple changes to
   whitespace within the message body.

   The provided canonicalization schemes do not tolerate changes in a
   message such as conversion between transfer encodings or addition of
   new message content.  It is useful to have these capabilities to
   allow for transport through gateways, and also for transport through
   handlers (such as mailing list services) that might add content that
   would invalidate a signature generated using the existing
   canonicalization schemes.

   This document presents a mechanism for declaring that a message
   underwent one of a handful of well-defined transformations prior to
   being re-signed by a mediator, so that a verifier might rewind such a
   modification and thereby confirm that the original signature still
   verifies against the original content.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

[Doug Foster]

You were partially right.   Outlook allows me to pick columns, but I forgot
that the feature was available.  

 I don't see the feature on two web MUAs or two phone MUAs that I checked.

Doug Foster


-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Alessandro Vesely
Sent: Tuesday, June 30, 2020 4:52 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

On Mon 29/Jun/2020 15:01:07 +0200 Doug Foster wrote:
> Very creative suggestion.   We need some new ideas.
> 
> However, I just checked my MUAs.   All of them assume that "To" is
> unimportant, so it is not displayed in the message list.   "To" only
appears
> in the message view (including the Preview pane).Without more
> visibility, it probably does not sufficiently solve the user interface
need.
> Which also suggests why I have not seen spammers try to manipulate 
> that field.


Can't you select what fields to display in the folder view?

The Sent folder must look boring if it only displays From:.

How about catchall folders?  Hm...  I though all email clients featured
customizable views nowadays.


Thank you for replying
Ale
-- 





















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

[Doug Foster]

Very creative suggestion.   We need some new ideas.

However, I just checked my MUAs.   All of them assume that "To" is
unimportant, so it is not displayed in the message list.   "To" only appears
in the message view (including the Preview pane).Without more
visibility, it probably does not sufficiently solve the user interface need.
Which also suggests why I have not seen spammers try to manipulate that
field.

Doug Foster

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Alessandro Vesely
Sent: Monday, June 29, 2020 5:19 AM
To: dmarc-ietf
Subject: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

Hi all,

I mentioned setting To: author instead of From: author-like, near the bottom
of a message[*] a week ago, but missed any WG comments on it.  That setting
would result if I run a mailing list "by hand", using a normal email client.
I'd hit reply and then add a bunch of Bcc:'s.  Of course, a suitable
template would insert a subject tag instead of "Re:", et cetera.

It'd be a cleaner solution than From: rewriting, inasmuch as it saves the
association between display names and addresses, for the sake of address
books consistency.  The anomaly of seeing authors in To: fields, with some
getting used to it, may even become a distinguished characteristic of
indirect mail flows.

How unbearable would that be?  And why?  Maybe some comments on this subject
can bring out some more details about the rightness or wrongness of the
various flavors of From: rewriting.


Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/dmarc/Mi6jz1SfgOnz7JjPUemkpJvFQ_w





























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Doug Foster]

Tactically, what I meant was "IETF should be able to ensure that IETF
messages are only released with verifiable IETF signatures".  

This would mean that either the first signature is not applied, the message
is not altered after the first signature is applied, or the first signature
is removed after the message is altered.   The current configuration leaves
open the suspicion that IETF has rogue software operating in its
environment.  I am aware that the DKIM specification says to treat an
unverifiable signature as a non-signature.   This is not a sufficient reason
to release your own organization's signatures onto the internet when you can
or should know that they will fail validation. 

Doug Foster


-Original Message-
From: Dave Crocker [mailto:d...@dcrocker.net] 
Sent: Friday, May 31, 2019 12:41 AM
To: fost...@bayviewphysicians.com
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

On 5/30/2019 7:49 PM, Douglas E. Foster wrote:
> I rather hoped that IETF would be the poster-boy for list processing 
> done correctly.

"Correctly"?

A message to a list is 'delivered' to the list. As in, it goes to the
specified addresse... the list.  A message from a list has been re-posted by
the list.

There are no constraints on the changes that are permitted to a message,
before it is re-posted.  There are no specifications that limit or direct
the behaviors of a list processor.

Different groups want and probably need different behaviors by a list
processor.  Periodic efforts to create such constraints have failed.

So while it would certainly make things easier to have list processors
behave in a simple, consistent manner, there's ample evidence that ain't
gonna happen.

If you can link the 'correctly' you are suggesting, to some documented,
community consensus, please cite it.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records?

[Doug Foster]

I have recently begun evaluating my incoming traffic for DKIM status, and I
suspect the results are relevant to your question.
   
These results are based on 768 unique domains, on signed messages, received
over a few adjacent days.  Messages that were blocked for any reason are
excluded from the analysis.  (I am not blocking based on DKIM status).

22  2.9% have DKIM signatures but fail verification 100%
15   2.0% have some DKIM verification failures

 70.9% have 100% rejection due to DNS record syntax errors
 1   0.1% have some rejections due to DNS record syntax errors

10  1.3% have 100% DKIM TXT lookup failures
  1 0.1% have some DKIM TXT lookup failures
---  
57  7.3%  have DKIM problems 

This failure rate is much higher than I would have expected.

When DKIM verification failures are detected, several possibilities must be
considered:
- an error exists in the signature generation algorithm at the source system
- modification or addition of a signed header during transit
- an error exists in the signature verification algorithm at the receiving
system

We receive very little indirect mail, so I believe that forwarding is not a
significant contributor to these problems.

For this type of debugging, it would be helpful if the receiving system
logged the message exactly as it was used for signature verification.  This
would permit independent verification using a tool such as the message
header checker at MxToolbox.com.   For the devices that I manage, this is
not the case.   Some of the devices do not log the full message at all.  The
one that does full logging only logs the message as it is relayed outbound.

My research also exposed a probable data-related bug on one mail server,
which causes it to generate incorrect signatures on a small percentage of
our outbound traffic.   I will be working with the vendor on that.

Doug Foster




  

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Wednesday, April 10, 2019 3:37 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] DNS library queries for DKIM and DMARC records?

Folks,

Howdy.

I'm trying to get a bit of education about reality.  Always dangerous, but
I've no choice...


For the software you know about, how are queries to the DNS performed, 
to obtain the TXT records associated with DKIM and/or DMARC?

I'm trying to understand the breadth and limitations of returned 
information that is filtered or passed by the code that is actually in 
use.  Which libraries and which calls from those libraries.


Thanks.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Email security beyond DMARC?

[Doug Foster]

I am all for anything that cuts unwanted email.   Not sure of the need to 
distinguish between spam and phishing.

 

I am assuming that I am the only one in this group not using DMARC.   You heard 
my problems with SPF.  

 

What do you do for SPF Exceptions?

· We have never seen a legitimate sender who needed an exception?

· We whitelist the source IP address and trust that it will only be 
used for appropriate domains?

· We whitelist the sender domain and hope it will never be spoofed?

· Something else?

 

Also, how do you handle SPF non-pass:   Neutral, Softfail, Syntax errors,  or  
Excessive nesting

 

Do you handle SPF any differently between senders with DMARC enforcement and 
those without?

 

Doug Foster

 

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Ken Simpson
Sent: Thursday, March 21, 2019 1:01 PM
To: John R Levine
Cc: IETF DMARC WG; Dotzero
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

 


> I'm going to have to disagree with you John. DMARC is about preventing
> direct domain abuse. It does not specifically address phishing as the bad
> guys can simply use cousin domains, homoglyphs, etc.

Well, it's abount a subset of phishing.  It's surely more about phishing 
than about spam.

 

IMHO, by cutting out direct domain spoofing, DMARC makes it easier for 
receivers to craft algorithms that spot impersonation attacks. Once you have 
configured DMARC, receivers can build - for example - a machine learning system 
that learns what your legitimate email looks like. They can use that same 
system to identify messages that look like your legitimate email but which do 
not actually originate from your domain.

 

If you want to detect domain impersonation or "brand" impersonation, you first 
have to have a verifiable ground truth corpus. That is what DMARC offers.

 

Regards,

Ken 

 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Email security beyond DMARC?

[Doug Foster]

Can one of you elaborate on the potential connection between PeP and DMARC,
or more generally, the connection beteen PeP and spam filtering? 

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of DAMY gustavo
Sent: Tuesday, March 19, 2019 2:03 PM
To: dmarc@ietf.org
Cc: Bernie Hoeneisen
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

Very useful links Bernie, thanks for the info.
I wonder if this working group will eventually will make reference  to the
concept of PeP  protocol to reinforce the usage of DMARC  you are mentioning
below? 

Best Regards
Gustavo Damy


-Original Message-
From: Bernie Hoeneisen 
Sent: Monday, March 18, 2019 1:58 PM
To: Douglas E. Foster 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

Hi Doug

On Sat, 16 Mar 2019, Douglas E. Foster wrote:

> I tried to understand what IETF is doing about email security, and 
> this working group seems to be the only surviving effort.  Based on 
> the index, the groups attention is focused on polishing the existing 
> DMARC implementaton rather than plowing new territory.  Given the 
> devastating effect of WannaCry and the success of other email-based 
> attacks, I think our work is far from finished.

You may want to have a look on some upcoming work. We just started a new
mailing list, which includes the topic of email security:

  MEDUP -- Missing Elements for Decentralized and Usable Privacy

To subscribe:

- https://www.ietf.org/mailman/listinfo/medup

Please find more information on:

- https://mailarchive.ietf.org/arch/msg/medup/mbrbhFekt_srXShzpCa4RiXgPbY

- https://mailarchive.ietf.org/arch/msg/pearg/oBjgAwG3_eoR6tpLQGTE_9OggzQ

The former also includes a list of Internet-Drafts describing the MEDUP
challenges.


Please be also informated that the LAMPS WG has requested a new work item on
email header protection to be added to its charter.


Hope that helps!

Best,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc