Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Murray S. Kucherawy]

On Mon, Dec 28, 2020 at 7:23 AM  wrote:

> P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
> standards-track status to be nothing short of astonishing. How on earth do
> you
> assess interoperability?
>

With the benefit of hindsight, that's a great question.  I'd have been
happy with Informational.  Indeed, the IESG evaluation record shows several
ADs brought that up, but none of them insisted, and thus it didn't get
changed.

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[John Levine]

In article  
you write:
>I believe at one time long ago there was an idea that a second possible
>usage for failure reports showing illegitimate mail was to give the domain
>owner evidence to present to an abuse desk or takedown vendor to get the
>illegitimate mail cut off at its source, but I don't know that for certain.

We did think of that, but at least in my experience all of the failure
reports that aren't legit messages handle were random forgeries from
Chinese networks where the spammers were just taking addresses from
their spam lists. Perhaps if my name were Paypal I'd see some targeted
fakery but it's not my impression that kind of faked mail is sent from
fixed sources.

>Without such a use case, failure reports regarding mail that the domain
>owner didn't cause to be originated are just noise, because there's no
>action that the domain owner can take.

Yup.  Still don't think failure reports need a separate document.

R's,
John

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Todd Herr]

On Mon, Dec 28, 2020 at 3:14 PM Alessandro Vesely  wrote:

> On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote:
> >
> > I am not opposed to the generic warning, but the following sentence in
> the
> > proposed warning gives me pause:
> >
> > "They are meant to aid domain owners to detect why failures reported
> > in aggregate form occurred."
> >
> > The implication, to me, in that sentence is that the failure report will
> be
> > sent to the party that originated the message,
>
>
> How do you derive that?  To me, the sentence seems to implicate that
> failure
> reports go to the same entity which receives aggregate reports.  That's
> not
> always going to be true either.  The point should be that the authority
> who
> decides where either kind of reports go is the same who publishes the
> public
> keys.  "Domain owners" is meant to indicate such authority.
>
>
Forgive me, as my words weren't clear here.

"[Failure reports] are meant to aid domain owners to detect why failures
reported in aggregate form occurred" says to me that the idea behind
failure reports is to put them in the hands of a party that can address the
failures.

DMARC validation failures can be caused either due to legitimate mail
(i.e., mail originated by or on behalf of the publisher of the DMARC
policy, a.k.a., the domain owner) failing authentication checks due to a
shortcoming in the authentication practices of the domain owner or some
other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
not originated by or on behalf of the domain owner, so mail intended to
fraudulently impersonate the domain), specifically the kind of mail that
DMARC is purported to be designed to stop.

All reports will go to the domain owner, and they should all go to the
domain owner, but the domain owner will have no interest in fixing the
authentication practices of the illegitimate mail streams identified by
failure reports, nor would it have the ability to do so even if it wanted
to.

I believe at one time long ago there was an idea that a second possible
usage for failure reports showing illegitimate mail was to give the domain
owner evidence to present to an abuse desk or takedown vendor to get the
illegitimate mail cut off at its source, but I don't know that for certain.
Without such a use case, failure reports regarding mail that the domain
owner didn't cause to be originated are just noise, because there's no
action that the domain owner can take.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


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] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Mon, 28 Dec 2020, Ned Freed wrote:
> I'm not ethusiastic about the split, but if that's what people want then so be
> it. I will say that my experience has been that doing so is usually more work
> and provides less benefit than you'd expect.



I recall agreeing to split out all of the reporting into a separate draft,
which makes some sense so the two parts can proceed separately, but not
further splitting aggregate and failure reports.


I was referring to the latter; I thought the reference to the drafts involved
made that clear. Sorry for the confusion.

The outcome of the split of MIME part one into four parts may offer some
limited insight here. IMO splitting message bodies from media types was a sound
logical split and ended up being a good thing. The split of conformance
criteria from media types, however, was a pretty serious lose - they now tend
to get ignored - so much so it's tempting to try and undo it.

But the split of media type registration from MIME/email was the real win, so
much so that it more than justified the entire activity.

The lesson, if there is one, is to go just far enough, but no further.
Splitting different reporting types smells a lot like "further" to me.

Ned

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Alessandro Vesely]

On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote:


I am not opposed to the generic warning, but the following sentence in the
proposed warning gives me pause:

"They are meant to aid domain owners to detect why failures reported
in aggregate form occurred."

The implication, to me, in that sentence is that the failure report will be
sent to the party that originated the message,



How do you derive that?  To me, the sentence seems to implicate that failure 
reports go to the same entity which receives aggregate reports.  That's not 
always going to be true either.  The point should be that the authority who 
decides where either kind of reports go is the same who publishes the public 
keys.  "Domain owners" is meant to indicate such authority.



Best
Ale
--





























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

Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[Hector Santos]

On 12/28/2020 1:17 PM, Michael Thomas wrote:


On 12/28/20 10:05 AM, Seth Blank wrote:

We agreed to split aggregate and failure reporting into different
documents, and this split was discussed on the list several times,
as well as at IETF 108.

The intention was to split apart the key components that
realistically get updated in different manners / at different cadences.

Aggregate reports and failure reports get used in wholly different
manners, have fundamentally different use cases, are implemented in
wildly different ways, and have completely different privacy and
security considerations. Hence, we agreed they should be split into
separate documents, so each can be concise, to the point, and
independently updated.



Does that mean all of the reporting? So that DMARC is really ADSP-bis?


When Seymour Cray was asked by his engineers building the Cray super 
computer, what primary language should they use for the new concept of 
Vectorization computing, Seymour responded; "I don't care what 
language we use ... just call it FORTRAN!"


It's marketing now, folks. It was what academia was teaching and 
industry engineers were using at the time.  Lets just get the 
DKIM-POLICY model done and call it DMARC. I really don't care because 
the basic fundamental concept has been established and to me, that is 
the most significant gain we have here - the DKIM-POLICY DNS LOOKUP 
concept has traction.


Yes, functionally, they were all the same, SSP, ADSP, DSAP and DMARC, 
from the basic LMAP "Lightweight Mail Authorization Protocol" concept 
of using an author domain for a DKIM-POLICY DNS lookup model. DMARC is 
the latest with a different syntax language that has gained traction. 
I support DMARC for that only reason -- its about TIME!!  I rather we 
define the protocol DKIM-POLICY Model because we already have a 
DKIM-TRUST model in the standard.


Nonetheless, now we can piggy-back off the _dmarc.example.com DNS 
lookup rather than _adsp._domainkey.example.com.


All the same concept, therefore all the same problems. Lets get DMARC 
done as a basic-lookup protocol and begin adding more to it related to 
3rd party authorization protocols which can piggy-back of the DNS 
call.   Reporting should of always been a separate consideration.


PS: Consider how many DNS lookups an all-things SMTP receiver does for 
port 25, non-authenticated/Authorized connections. For wcSMTP:


At connection:

IP Geo Location Filter
IP DNS RBL

At SMTP before DATA

Maybe EHLO domain DNS matching check
Maybe EHLO domain SPF check
Maybe MAIL FROM SPF check
Maybe MAIL FROM Call Back Verifier (MX)

At SMTP DATA if it gets this far:

Maybe DKIM check
Maybe ADSP 5322.From check
Maybe DMARC 5322.From check
Maybe ATPS 5322.From check
Maybe VBR 5322.From check

Overall, there are a lot of calls today per SMTP session.

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


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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[John Levine]

In article  
you write:
>Is it not also important to note that the recipient of the failure report
>(the domain owner) may not be the originator of the failed message, and
>that fact should also weigh into the consideration of deciding whether to
>generate such reports?

The exact same issue applies to aggregate reports which can leak a
fair amount of PII from domains with modest amounts of traffic so you
can guess who sent what.  See my prior message about the county government.

R's,
John

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

Somehow this boilerplate seems especially ironic.

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

Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>Aggregate reports and failure reports get used in wholly different manners,
>have fundamentally different use cases, are implemented in wildly different
>ways, and have completely different privacy and security considerations.

All true, but the actual specs overlap quite a lot. For example, where
does section 7.1 about verifying external destinations go? If the
answer is that it's copied into two documents, that is bad.

I think we've seen that for failure reporting there is nothing to
change beyond updating the privacy considerations, so leaving all the
reporting in one document is unlikely to cause schedule problems.

R's,
John

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

Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[Michael Thomas]

On 12/28/20 10:05 AM, Seth Blank wrote:
We agreed to split aggregate and failure reporting into different 
documents, and this split was discussed on the list several times, as 
well as at IETF 108.


The intention was to split apart the key components that realistically 
get updated in different manners / at different cadences.


Aggregate reports and failure reports get used in wholly different 
manners, have fundamentally different use cases, are implemented in 
wildly different ways, and have completely different privacy and 
security considerations. Hence, we agreed they should be split into 
separate documents, so each can be concise, to the point, and 
independently updated.




Does that mean all of the reporting? So that DMARC is really ADSP-bis? 
The reporting is clearly a completely separate protocol from the policy 
mechanism, and is far more likely to mutate than the base policy 
mechanism which has changed very little from ADSP. I mean, as far as I 
can tell the main change from ADSP is to include spf too.


Mike

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

Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[Seth Blank]

We agreed to split aggregate and failure reporting into different
documents, and this split was discussed on the list several times, as well
as at IETF 108.

The intention was to split apart the key components that realistically get
updated in different manners / at different cadences.

Aggregate reports and failure reports get used in wholly different manners,
have fundamentally different use cases, are implemented in wildly different
ways, and have completely different privacy and security considerations.
Hence, we agreed they should be split into separate documents, so each can
be concise, to the point, and independently updated.

Seth, as Chair

On Mon, Dec 28, 2020 at 10:00 AM Tim Wicinski  wrote:

>
> I will admit my memory can get pretty hazy, but I agree with Mr Levine - I
> remember splitting out reporting,
> but only as one document.
>
> The Working Group can always make a compelling case to change this
>
> tim
>
>
> On Mon, Dec 28, 2020 at 12:06 PM John R Levine  wrote:
>
>> On Mon, 28 Dec 2020, Ned Freed wrote:
>> > I'm not ethusiastic about the split, but if that's what people want
>> then so be
>> > it. I will say that my experience has been that doing so is usually
>> more work
>> > and provides less benefit than you'd expect.
>>
>> I recall agreeing to split out all of the reporting into a separate
>> draft,
>> which makes some sense so the two parts can proceed separately, but not
>> further splitting aggregate and failure reports.
>>
>> 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
>>
> ___
> 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] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[Tim Wicinski]

I will admit my memory can get pretty hazy, but I agree with Mr Levine - I
remember splitting out reporting,
but only as one document.

The Working Group can always make a compelling case to change this

tim


On Mon, Dec 28, 2020 at 12:06 PM John R Levine  wrote:

> On Mon, 28 Dec 2020, Ned Freed wrote:
> > I'm not ethusiastic about the split, but if that's what people want then
> so be
> > it. I will say that my experience has been that doing so is usually more
> work
> > and provides less benefit than you'd expect.
>
> I recall agreeing to split out all of the reporting into a separate draft,
> which makes some sense so the two parts can proceed separately, but not
> further splitting aggregate and failure reports.
>
> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[John R Levine]

On Mon, 28 Dec 2020, Ned Freed wrote:

I'm not ethusiastic about the split, but if that's what people want then so be
it. I will say that my experience has been that doing so is usually more work
and provides less benefit than you'd expect.


I recall agreeing to split out all of the reporting into a separate draft, 
which makes some sense so the two parts can proceed separately, but not 
further splitting aggregate and failure reports.


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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Tim Wicinski]

I would drop that whole third sentence, and mention sending such reports
may contain PII.
The document can refer the reader to non-IETF documents for information,
but in general
we do technical standards, and stay away from policy decisions in standards
track documents.


tim


On Mon, Dec 28, 2020 at 10:57 AM Michael Thomas  wrote:

>
> On 12/28/20 7:48 AM, Todd Herr wrote:
>
>  not a lawyer, but providing A with some information about a message that
> A sent to X seems different, from a privacy perspective, than providing A
> with some information about a message impersonating A that B sent to X, and
> I thought perhaps the generic warning might mention this distinction, if
> possible. Something like:
>
> Security considerations
>
> Failure reports provide detailed information about the failure of a
> single message or a group of similar messages failing for the same
> reason. They are meant to aid domain owners to detect why failures
> reported in aggregate form occured. It is important to note these
> reports can contain either the header or the entire content of a
> failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
> REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
> REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain
> personally identifiable information, which should be considered when
> deciding
> whether to generate such reports.
>
>
>
> This is a tempest in a tea pot. This is an issue with the originating
> domain and nobody else. They can send it to a third party even if the url
> lists them to receive the report first.  The receiving domain can't know
> what they will do with the report, and the originating domain has already
> seen the mail in clear text before it was sent. IETF should stay out of the
> business of being nannies that it has no way to enforce.
>
> Mike
> ___
> 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] auth-res vs. dmarc

[Hector Santos]

On 12/28/2020 8:17 AM, Todd Herr wrote:

On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas mailto:m...@mtcc.com>> wrote:


I installed this handy dandy t-bird dkim verifier extension which
also
allows you to just use the upstream auth-res.  After fixing a bug
in it,
I could see that it lists DMARC as a fail when DKIM failed, but SPF
passed. The _dmarc record has p=none, so it seems really odd to call
that a DMARC failure. Shouldn't it just be using the appropriate
p= tag
instead of "fail"? Is this left over from when Auth-res was mainly
for dkim?


A DMARC pass verdict requires not only that SPF or DKIM pass, but also
that the SPF or DKIM domain in question align with the DMARC
(RFC5322.From) domain. A message such as the following:

  * Return-Path: mailto:f...@a.net>>
  * DKIM domain: b.org 
  * From: b...@c.com 

Can get an SPF pass for a.net  and have its DKIM
signature validate, but still fail DMARC for c.com 
because neither a.net  nor b.org  align
with c.com .

Can you share the example auth-res header(s) in question along with
the DMARC policy record(s) for the message(s)?
--


FWIW

For your message, the wcSMTP MDA verified and produced the follow AR 
for you:


Authentication-Results: dkim.winserver.com;
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 dmarc=fail policy=none author.d=dmarc.ietf.org signer.d=ietf.org 
(unauthorized signer);
 dkim=fail (DKIM_SIGNATURE_BAD) header.d=ietf.org header.s=ietf1 
header.i=ietf.org;
 dmarc=dkim-fail policy=none author.d=dmarc.ietf.org 
signer.d=ietf.org (unauthorized signer);
 dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=valimail.com 
header.s=google2048 header.i=valimail.com;
 dmarc=dkim-fail policy=none author.d=dmarc.ietf.org 
signer.d=valimail.com (unauthorized signer);


bottom up read,

By the time your message (my list copy) was echoed to me, as expected 
with the ietf.org MLM, your original body integrity was lost, hence a 
body-mismatch will be detected with all downlink DKIM verifiers.


The original DKIM idea for MLM correction (or middle-ware in general) 
was to perform a resigning by the MLM as a 3rd party signer. But we 
never corrected the authorization protocol for the 3rd party signers 
like is done with SPF allowing for 3rd party mailers to exist within 
it output mail sender framework.


Here is the problem with rewriting which the AR recorded illustrates 
-- who is the POLICY holder here?  You or the IETF (ietf.org or 
dmarc.ietf.org)?


Valmail.com does not have a policy, like ATPS, that will authorized 
ietf.org or dmarc.ietf.org as a resigner.   If you had this zone record:


;
; DMARC/ATPS Zone Records for author-domain: valimail.com
; Generated by wcMakeDMARC v4.00 (c) copyright 2020 Santronics 
Software, Inc.

; See https://secure.winserver.com/public/wcdmarc
;

_dmarc TXT ("v=dmarc1; p=reject; atps=y; asl=ietf.org,dmarc.ietf.org;")

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")
xxv4fo4ieaguvlupvusha3j2x7ici4za._atps  TXT ("v=atps01; 
d=dmarc.ietf.org;")


Then our wcDMARC verifier would validate your message and stamp the AR 
with an authorized resigner data bit.  However, this is true when 
rewriting is not applied.


In practice, we have a "contract" as a list member to accept what the 
IETF MLM does, to a degree, to receive its output. But I don't expect 
any original protection to be lost.  Valimail.com was protected on 
input.  On output, it was no longer protected once it passes through 
the IETF MLM.


Consider a rewrite is not correct when it used two different domains. 
My understanding for the intent of this unfortunate introduction into 
the mail world, the whole point was make it a 1st party signature so 
that the author and signer identities matched:


ADID  Author Identity: dmarc.ietf.org
SDID  Signer Identity: ietf.org   <--- SHOULD BE signed by dmarc.ietf.org

Even if it was signed by dmarc.ietf.org, its DMARC policy is p=none, 
so who cares what is done with valimail.com messages?  Product 
engineering common sense is to not destroy the original policy 
protection Valimail.com had. If the rewrite logic is going to be 
applied only when an incoming domain has a DMARC p=reject|quarantine 
policy, then the rewrite MUST have a matching level of protection when 
it changes the author identity To me, this is the only possible way 
for a rewrite mlm logic to minimize the damage created by destroying 
the original intent and protection of a DMARC-based restricted domain.


This failure is feeding any anticipated growth for "Deep AI Mail 
engines"  that indicate valimail.com has a significant failure rate, 
100% of the time coming out of the IETF.


If I was valimail.com, as a product developer, you should support the 
easy ATPS protocol. Just add the domains you want to authorized as a 
resigner and hopefully with ATPS endorsement by ValiMa

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Michael Thomas]

On 12/28/20 7:48 AM, Todd Herr wrote:
 not a lawyer, but providing A with some information about a message 
that A sent to X seems different, from a privacy perspective, than 
providing A with some information about a message impersonating A that 
B sent to X, and I thought perhaps the generic warning might mention 
this distinction, if possible. Something like:


Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain
personally identifiable information, which should be considered
when deciding
whether to generate such reports.




This is a tempest in a tea pot. This is an issue with the originating 
domain and nobody else. They can send it to a third party even if the 
url lists them to receive the report first.  The receiving domain can't 
know what they will do with the report, and the originating domain has 
already seen the mail in clear text before it was sent. IETF should stay 
out of the business of being nannies that it has no way to enforce.


Mike

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Todd Herr]

On Mon, Dec 28, 2020 at 9:12 AM Dotzero  wrote:

>
>
> On Mon, Dec 28, 2020 at 8:30 AM Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
>> On Thu, Dec 24, 2020 at 1:55 PM John R Levine  wrote:
>>
>>>
>>> Security considerations
>>>
>>> Failure reports provide detailed information about the failure of a
>>> single message or a group of similar messages failing for the same
>>> reason. They are meant to aid domain owners to detect why failures
>>> reported in aggregate form occured. It is important to note these
>>> reports can contain either the header or the entire content of a
>>> failed message, which in turn may contain personally identifiable
>>> information, which should be considered when deciding whether to
>>> generate such reports.
>>>
>>>
>> Sorry; late to the party due to the holiday...
>>
>> Is it not also important to note that the recipient of the failure report
>> (the domain owner) may not be the originator of the failed message, and
>> that fact should also weigh into the consideration of deciding whether to
>> generate such reports?
>>
>> If A publishes a DMARC policy record, and a bad actor sends intentionally
>> fraudulent mail using A's domain as the RFC5322.From to addresses that are
>> not among A's current customer base, and therefore unknown to A, sending
>> failure reports to A that don't redact these email addresses reveals PII to
>> A that A has no business receiving.
>>
>>
> Todd,
>
> Would this be akin to the proprietary and confidential information, as
> indicated in the footer of your email message, which you sent to a publicly
> accessible list operating under IETF's "Note Well" policy?  Some might
> argue that receipt of this information in DMARC failure reports is a
> feature and not a bug. Just as the ability to use WHOIS in fighting abuse
> has been gutted as a result of GDPR, do we really want to go down a path of
> warning people of "dangers" in such an un-nuanced manner?
>
> I agree with John and others that a generic warning regarding security and
> privacy issues is the more useful approach given that this is a technical
> standard and vague hand waving is not particularly useful as an
> implementation guide. For bad guys using/abusing real email addresses as
> destinations, the privacy ship has sailed as someone somewhere got breached
> or the addresses got scraped. The same goes for originating From and Mail
> From addresses, except the originating domain is already aware of them.
> Given the choice between writing a book that few will read and even less
> will understand, and writing a brief generic warning, I choose short and
> generic.
>
> Michael Hammer
>

Michael,

I am not opposed to the generic warning, but the following sentence in the
proposed warning gives me pause:

"They are meant to aid domain owners to detect why failures reported in
aggregate form occured."


The implication, to me, in that sentence is that the failure report will be
sent to the party that originated the message, and that's not always going
to be true. All failure reports will be sent to the domain owner, but the
domain owner will not always be the originating party for the message in
the failure report.

I'm not a lawyer, but providing A with some information about a message
that A sent to X seems different, from a privacy perspective, than
providing A with some information about a message impersonating A that B
sent to X, and I thought perhaps the generic warning might mention this
distinction, if possible. Something like:

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain
personally identifiable information, which should be considered when
deciding
whether to generate such reports.


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


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] Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote:
>> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote:
>>> I Believe I agree with the current version, but can someone post what we
>>> think is the final text?
>
> See below, with the two changes mentioned before and Mr Copy Edit's minor
> tightening up which I hope are not controversial.
>
> Ale said:
>> I posted it here:
>> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting
>
> Hold it. I don't recall that we agreed to break failure reports into a 
separate
> document.




The fact that draft-ietf-dmarc-failure-reporting-00 exists on IETF datatracker
seems to confirm WG consensus.


I'm not ethusiastic about the split, but if that's what people want then so be
it. I will say that my experience has been that doing so is usually more work
and provides less benefit than you'd expect.

That said, the adoption of something as a WG document, especially one with an
intended status of  and in the absence of a corresponding charter update,
doesn't really mean much. 


I also don't see where the discusssion leading to the WG consensus on the
split occurred on the mailing list. Perhaps you could point me at it?



But see also:
https://mailarchive.ietf.org/arch/msg/dmarc/2DsSazvE9QxFjVSeg_mdNlRMETM




> It makes more work and I see no agreement to change anything beyond the
> security paragraph.  In particular, we have nothing to offer on what one
> might or might not redact.




I still think it'd be a good idea to mention RFC 6590...


Why? RFC 6589 documents a generic approach to partial information hiding. It
does not specify how to apply this technique to DMARC failure reports, and
doing so effectively requires a careful assessment of what needs to be hidden
and what does not, and that in turn drags in all of the specifics we need to
avoid in a base document of this sort.

Indeed, as things stand, since the intent of RFC 6589 is to preserve some
information, we can't even say it solves any particular problem with DMARC
failure reports.

Ned

P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on earth do you
assess interoperability? 


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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Dotzero]

On Mon, Dec 28, 2020 at 8:30 AM Todd Herr  wrote:

> On Thu, Dec 24, 2020 at 1:55 PM John R Levine  wrote:
>
>>
>> Security considerations
>>
>> Failure reports provide detailed information about the failure of a
>> single message or a group of similar messages failing for the same
>> reason. They are meant to aid domain owners to detect why failures
>> reported in aggregate form occured. It is important to note these
>> reports can contain either the header or the entire content of a
>> failed message, which in turn may contain personally identifiable
>> information, which should be considered when deciding whether to
>> generate such reports.
>>
>>
> Sorry; late to the party due to the holiday...
>
> Is it not also important to note that the recipient of the failure report
> (the domain owner) may not be the originator of the failed message, and
> that fact should also weigh into the consideration of deciding whether to
> generate such reports?
>
> If A publishes a DMARC policy record, and a bad actor sends intentionally
> fraudulent mail using A's domain as the RFC5322.From to addresses that are
> not among A's current customer base, and therefore unknown to A, sending
> failure reports to A that don't redact these email addresses reveals PII to
> A that A has no business receiving.
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* todd.h...@valimail.com
> *p:* 703.220.4153
>
>
> 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.
>

Todd,

Would this be akin to the proprietary and confidential information, as
indicated in the footer of your email message, which you sent to a publicly
accessible list operating under IETF's "Note Well" policy?  Some might
argue that receipt of this information in DMARC failure reports is a
feature and not a bug. Just as the ability to use WHOIS in fighting abuse
has been gutted as a result of GDPR, do we really want to go down a path of
warning people of "dangers" in such an un-nuanced manner?

I agree with John and others that a generic warning regarding security and
privacy issues is the more useful approach given that this is a technical
standard and vague hand waving is not particularly useful as an
implementation guide. For bad guys using/abusing real email addresses as
destinations, the privacy ship has sailed as someone somewhere got breached
or the addresses got scraped. The same goes for originating From and Mail
>From addresses, except the originating domain is already aware of them.
Given the choice between writing a book that few will read and even less
will understand, and writing a brief generic warning, I choose short and
generic.

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Todd Herr]

On Thu, Dec 24, 2020 at 1:55 PM John R Levine  wrote:

>
> Security considerations
>
> Failure reports provide detailed information about the failure of a
> single message or a group of similar messages failing for the same
> reason. They are meant to aid domain owners to detect why failures
> reported in aggregate form occured. It is important to note these
> reports can contain either the header or the entire content of a
> failed message, which in turn may contain personally identifiable
> information, which should be considered when deciding whether to
> generate such reports.
>
>
Sorry; late to the party due to the holiday...

Is it not also important to note that the recipient of the failure report
(the domain owner) may not be the originator of the failed message, and
that fact should also weigh into the consideration of deciding whether to
generate such reports?

If A publishes a DMARC policy record, and a bad actor sends intentionally
fraudulent mail using A's domain as the RFC5322.From to addresses that are
not among A's current customer base, and therefore unknown to A, sending
failure reports to A that don't redact these email addresses reveals PII to
A that A has no business receiving.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


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] auth-res vs. dmarc

[Todd Herr]

On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas  wrote:

>
> I installed this handy dandy t-bird dkim verifier extension which also
> allows you to just use the upstream auth-res.  After fixing a bug in it,
> I could see that it lists DMARC as a fail when DKIM failed, but SPF
> passed. The _dmarc record has p=none, so it seems really odd to call
> that a DMARC failure. Shouldn't it just be using the appropriate p= tag
> instead of "fail"? Is this left over from when Auth-res was mainly for
> dkim?
>
>
A DMARC pass verdict requires not only that SPF or DKIM pass, but also that
the SPF or DKIM domain in question align with the DMARC (RFC5322.From)
domain. A message such as the following:

   - Return-Path: 
   - DKIM domain: b.org
   - From: b...@c.com

Can get an SPF pass for a.net and have its DKIM signature validate, but
still fail DMARC for c.com because neither a.net nor b.org align with c.com.

Can you share the example auth-res header(s) in question along with the
DMARC policy record(s) for the message(s)?

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


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