Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

From: Todd Herr <[email-masked]>
Date: Tue, 19 Jan 2021 09:02:39 -0500

Picking up the thread on a ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...

In reviewing the discussion, I don't believe a consensus has emerged on how
to implement this feature, or even whether to do it.

John proposed a new tag, ruap, for specifying HTTPS URIs (along with mailto:
and supposedly others that may be implemented in the future), while Ale
proposed different ways to express it in the existing rua tag.

Concerns were voiced about interoperability impacts for Ale's suggestions,
and Ale committed to running an experiment to see if there were changes to
his inbound report flows when he implemented one variant for expressing the
URI in the rua tag (     v=DMARC1; p=none; rua=mailto:[email-masked],
mailto:[email-masked], OR-https://service.example/report/;), but
there have been no subsequent posts by him to the list to report on results.

Other concerns were raised about privacy and security issues that might be
inherent in and unique to adding this kind of functionality, issues that
may not have been fully discussed or understood by the community over the
years. There was also a question about whether or not this is something
that people are asking for.

Hatless, it seems to me that the safest implementation of this feature,
presuming the security and privacy concerns can be addressed to the
satisfaction of those who raised them, would be to add a new tag, as John
has proposed, so as to minimize interoperability issues. I say "minimize",
rather than "avoid", simply because while RFC 7489 says "Unknown tags MUST
be ignored.", I don't believe we can say with 100% certainty that all
implementations of DMARC policy record parsing in the known world (both by
report generators and third parties who advise domains on how to publish
DMARC records), implementations that work now, won't "break" if a new tag
is introduced. Of course, that'd be their problem, not ours, because they
weren't following the existing rules.

As editor, I seek guidance from the working group on how to proceed here.

On Thu, Dec 31, 2020 at 11:35 AM Alessandro Vesely <[email-masked]> wrote:

> On Thu 31/Dec/2020 16:37:38 +0100 John R Levine wrote:
> > On Thu, 31 Dec 2020, Alessandro Vesely wrote:
> >
> >> On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote:
> >>> [ add ruap= to allow https in preference to mailto ]
> >>
> >> I still like better sticking to a unique tag (rua=) and applying
> OR-slashes.
> >> With a comma, it is backward compatible:
> >>
> >> v=DMARC1; p=none; rua=mailto:[email-masked], mailto:
> [email-masked], /https://service.example/report/;
> >
> > No, it's invalid according to the syntax in RFC 7489.
>
>
> I see.  We have:
>
>      dmarc-auri      = "rua" *WSP "=" *WSP
>                         dmarc-uri *(*WSP "," *WSP dmarc-uri)
>
>      URI             = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>
>      scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
>
> So /https cannot be a scheme.  How about:
>
>      v=DMARC1; p=none; rua=mailto:[email-masked], mailto:
> [email-masked], OR-https://service.example/report/;
>
>
> > We have no idea what existing implementations do with DMARC records with
> syntax errors.
> >
> > Here's an experiment -- put that slash syntax in the rua= in your DMARC
> record
> > and see who does or doesn't continue sending reports.
>
>
> Done, with the second alternative.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*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.

---

From: Hector Santos <[email-masked]>
Date: Tue, 19 Jan 2021 10:27:37 -0500

On 1/19/2021 9:02 AM, Todd Herr wrote:>
> Other concerns were raised about privacy and security issues that
> might be inherent in and unique to adding this kind of functionality,
> issues that may not have been fully discussed or understood by the
> community over the years. There was also a question about whether or
> not this is something that people are asking for.

Reporting concepts were in the each DKIM Policy proposal (SSP, DSAP, 
ADSP) -- a "-r" tag option to send reports. The main concerns were 
unsolicited report abuse.   The DSAP proposal (my own) recognize it 
could be optional so it provided:

    https://tools.ietf.org/html/draft-santos-dkim-dsap-00	

    4.5.  DSAP Tag: r=<abuse-address>

    This tag is optional.  If not defined, the default is no abuse-
    address is available.

    <abuse-address> is either the user-part or a FQDN email address to
    optional send abuse reports.

    Examples:
       r=abuse
       r=[email-masked]

    If only the user-part is defined, then the full address is
    established by using the originating address domain.

    DKIM verifiers have the option to honor or not honor this reporting
    address.  DKIM signers MUST be aware this reporting address may not
    be utilized by verifiers.

    Verifiers should be aware this reporting address can be a source of
    an report attack vector (Section 7.4).  One possible implementation
    considerations would to limit the report to one report only and to
    track the reception and/or response of the reporting.

but the Section 7.4 discussion was TBD.

>
> Hatless, it seems to me that the safest implementation of this
> feature, presuming the security and privacy concerns can be addressed
> to the satisfaction of those who raised them, would be to add a new
> tag, as John has proposed, so as to minimize interoperability issues.
> I say "minimize", rather than "avoid", simply because while RFC 7489
> says "Unknown tags MUST be ignored.", I don't believe we can say with
> 100% certainty that all implementations of DMARC policy record parsing
> in the known world (both by report generators and third parties who
> advise domains on how to publish DMARC records), implementations that
> work now, won't "break" if a new tag is introduced. Of course, that'd
> be their problem, not ours, because they weren't following the
> existing rules.

We can not continue to design Internet protocols without upward design 
considerations. This is part of the forward and backward compatibility 
design concepts.  Any problem would be a known tag with new 
functionality than originally expected. Sure, we can't say it will not 
happen, but its going to be a very low percentage, if any.  They have 
to fix it.

> As editor, I seek guidance from the working group on how to proceed here.

I am for a URI protocol method as part of the current tag rather than 
a new a separate tag.

However, in principle, I don't see any issue with adding new tags, in 
fact, I am still here on the basis extended protocols will emerged 
once the base protocol is completed.  ATPS will be available to 
piggyback off the DMARC record as it did off ADSP.  The ATPS protocol 
adds "atps=y" tag to the DMARC record.  We have never received reports 
of issues related to extended tags.

There is a also a small scale version called ASL (Authorized Signer 
List) tag which defines a few domains authorized as resigners; for 
example:

asl=example1.com, example2.com, ietf.org, gmail.com

If you believe that adding a new tag is going to be a problem for 
DMARC, then we might as well come up with a new DKIM Policy model and 
a new resource record lookup name.

Imo, you guys are really missing the boat here.  Extended tags is a 
major part of a DKIM POLICY model future simply because we have not 
yet imagine all the needs to make it work well and integrate with 
other concepts.  In DSAP, for example, we had tags such as:

+============================================================+
| Description            |  DSAP Record Tag                  |
|============================================================|
| Version tag            |  v=<dsap-version>/<dkim-version>  |
|------------------------------------------------------------|
| Original party signing |  op=<signing-policy>              |
| practice               |                                   |
|------------------------------------------------------------|
| 3rd party signing      |  3p=<signing-policy>              |
| practice               |                                   |
|------------------------------------------------------------|
| Authorized List of     |  dl=<dom-list>                    |
| 3rd party domains      |                                   |
|------------------------------------------------------------|
| Signature Hashing      |  a=<hash-algorithm>               |
| Method                 |                                   |
|------------------------------------------------------------|
| Reporting address      |  r=<abuse-address>                |
|------------------------------------------------------------|
| Note or comment        |  n=<note>                         |
|------------------------------------------------------------|
| Testing flag           |  t=<testing-flag>                 |
|------------------------------------------------------------|
| Unauthorized signature |  fa=<failure-handling>            |
| failure handling       |                                   |
|------------------------------------------------------------|
| Invalid Signature      |  fs=<failure-handling>            |
| failure handling       |                                   |
|------------------------------------------------------------|
| Signature Expiration   |  fx=<failure-handling>            |
| failure handling       |                                   |
+------------------------------------------------------------+

The optional note tag (n=) allows a domain to store a human readable 
note or comment regarding the DSAP DNS record.  Its purpose is 
considered to be diagnostic in nature.

The fa=, fs= and fx= tags were based on discussion to offer specific 
handling instructions based on specific possible errors:

4.8.  DSAP Tags: fa=<failure-handling>; fs=<failure-handling>;
       fx=<failure-handling>;

    The fa=, fs, and fx= tags define the domain preferred rejection
    action policy a verifier is recommended to perform when an
    unauthorized signature, failed signature or expired signature is
    detected, respectively.

    The fa= tag defines the handling for failed signature authorization.
    The fs= tag defines the handling for failed signature verfication,
    and the fx= tag defines the handling when a signature expired or key
    is revoked.

    Failed signature include failures related to the DKIM-Signature
    hashing, syntax and encryption verification process.

    <failure-handling> values:

    FAIL                The verifer MUST reject the transaction when
                        failure is detected.  (Default)

    SOFTFAIL            The verifer SHOULD reject the transaction when
                        failure is detected.

    IGNORE              The verifer SHOULD NOT reject the transaction
                        when failure is detected.  This value may be
                        defined by the domain to signify the domain is
                        testing DKIM and failure may occur unexpectedly.
                        Verifiers SHOULD consider tracking this handler
                        value for abuse.

    The fa= and fs= tags are optional with default values of SOFTFAIL.

    Examples:

    fa=fail;fs=fail; fx=fail;  Domain has a MUST reject immediate policy
                        for unauthorized, failed or expired signatures.

    fa=fail;            Domain has a MUST reject immediate policy for
                        unauthorized signatures and a SHOULD reject
                        immediate policy for failed and expired
                        signatures.

    undefined values;   DOMAIN has a SHOULD reject immediate policy for
                        all failures.

    fs=fail;  fx=fail;  Domain has a SHOULD reject immediate policy for
                        unauthorized signatures and a MUST reject
                        immediate policy for failed and expired
                        signatures.

My point is simple, extended tags MUST be part of the protocol's 
extendability. If there is evidence with 100% sureness there going to 
be a significant compatibility problem with legacy software that can 
not be corrected, then the only option is a new DMARC version 2 
resource record.

I don't think we (I know I can't) can continue with DMARCbis without 
Extended Tag support and be hesitant to invent them because there is a 
compatibility problem.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Jan 2021 20:18:27 +0100

On Tue 19/Jan/2021 15:02:39 +0100 Todd Herr wrote:
> URI in the rua tag (v=DMARC1; p=none; rua=mailto:[email-masked], 

It seems to work perfectly.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Tue, 19 Jan 2021 14:22:03 -0500

It seems that I was not successful in conveying my meaning in a few
statements, so allow me to try again...

> could be optional so it provided:

My mention of "other concerns ... about privacy and security" is in
reference to a post in this thread that Mike Hammer made in early December,
where he wrote:

"I don't recall a strong security and privacy concerns discussion around
HTTP(S) reporting. Presumably the report contents are protected in transit
but to what extent is access by arbitrary parties an issue. Notwithstanding
that things like GDPR are political issues, they are worth noting as a real
life operational consideration."

> However, in principle, I don't see any issue with adding new tags,

I'm sorry, but I'm not clear on what position you're advocating here. You
assert that "any problem would be a known tag with new functionality than
originally expected" (which would seem to argue for using a new tag such as
ruap) but then you state that you're for a URI protocol method as part of
the current tag (which would seem to argue against using ruap, but instead
figuring out a way to add https: to rua), but then you state you don't see
any issue with adding new tags.

Can you help me understand your position better, please?

[snip]

> Extended Tag support and be hesitant to invent them because there is a
I wasn't arguing against adding a new tag, merely being cautious, perhaps
overly so, in refusing to assert with 100% certainty that doing so won't
cause any problems.

--

---

From: Todd Herr <[email-masked]>
Date: Tue, 19 Jan 2021 14:25:27 -0500

> It seems to work perfectly.
Can you provide more details, please?

Are you receiving reports by HTTPS, or have you not seen any reduction in
reports, or both, or other?

--

---

From: "John Levine" <[email-masked]>
Date: 19 Jan 2021 20:54:28 -0500

>life operational consideration."

I saw this but I still don't understand it. The chances of an HTTP
POST getting snooped on are far less than any kind of e-mail.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 19 Jan 2021 21:31:51 -0500

>reports, or both, or other?

I didn't try Ale's OR- thing but I did add an https URL to my rua= tag and set up
a web server to catch any POST or PUT traffic.

Other than a few Russian probes shortly after I published it, it's
gotten no traffic at all.

I suppose the good news is that nobody implemented the underspecifed
report URL in one of the earlier DMARC drafts.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Jan 2021 08:08:30 -0500

On 1/19/2021 2:22 PM, Todd Herr wrote:
>
> I'm sorry, but I'm not clear on what position you're advocating here.
> You assert that "any problem would be a known tag with new
> functionality than originally expected" (which would seem to argue for
> using a new tag such as ruap) but then you state that you're for a URI
> protocol method as part of the current tag (which would seem to argue
> against using ruap, but instead figuring out a way to add https: to
> rua), but then you state you don't see any issue with adding new tags.
>

Yes, I saw. Allow me to clarify. Diffs in tags vs diffs in tag values.

Overall, I think we should not be "afraid" to invent use new tags. 
This is the main consideration I was pointing out.  Implementation 
MUST not fail with unknown tags.

However, with a known tag, in this case the reporting mechanism, I can 
see now the only delivery protocol defined was "mailto:"

I don't think we can add a "https:" here without probably causing some 
issue with some existing implementations, i.e. report generated by the 
assumed email address will fail (no delivery).  But we don't know for 
sure.  An implementation may not fail if its checking for the 
"mailto:" prefix. Reports would be skipped if HTTPS is not supported 
by the verifier.

I think we should add/defined the "https:" for the exist reporting tag 
ABNFs. The only one who will understand it are implementations with 
HTTPS delivery support only. Others will simply not be able to send a 
report to a domain that desires HTTPS delivery.

I think the worst that will happen is a non-https implementation will 
have one of the following:

1 - check for the prefix "mailto:" and extract the address at 6 position
2 - not check, assume plus 6 has the a valid address.

In each case, it will fail (no https delivery supported), #2 may be an 
a wasted delivery attempt to an invalid email address.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 20 Jan 2021 19:58:21 +0100

>> reports, or both, or other?

No, I didn't put a real server's URL.  Just this:
"v=DMARC1; p=none; rua=mailto:[email-masked], OR-https://service.example/report/; ruf=mailto:[email-masked];"

> a web server to catch any POST or PUT traffic.

John's record looks more workable, but it's still fluffy:

"v=DMARC1; p=none; rf=afrf; rua=mailto:[email-masked],https://dmreport.abuse.net/dmreport/; ruf=mailto:[email-masked]"

> I suppose the good news is that nobody implemented the underspecified

It is not underspecified.  It specifies the /mailto:/ scheme.  With forward-looking shrewdness, it further specifies:

7.2.1.2.  Other Methods

    The specification as written allows for the addition of other
    registered URI schemes to be supported in later versions.

However, one cannot make guesses about what a receiver would do with, say, rua=fax:+13165550321.  For mailto: they know to send a gzip attachment.  Nothing is specified for https:, even if the scheme is known.  OR-https: is an unknown pseudo-scheme which, as far as parsing is concerned, can be discarded just like https: and fax:.

Likewise, the spec provides for a registry of tags and says that unknown tags must be ignored.  Therefore it is possible to safely add a new tag.  Let's see two cases:

"v=DMARC1; p=none; ruap=mailto:[email-masked], https://service.example/report/; rua=mailto:[email-masked], mailto:[email-masked];"
"v=DMARC1; p=none; ruap=https://example.com/dmarcaggr, https://service.example/report/; rua=mailto:[email-masked], mailto:[email-masked];"

Using my OR- syntax, they would be, respectively:

"v=DMARC1; p=none; rua=mailto:[email-masked], mailto:[email-masked], OR-https://service.example/report/;"
"v=DMARC1; p=none; rua=mailto:[email-masked], OR-https://example.com/dmarcaggr, mailto:[email-masked], OR-https://service.example/report/;"

One last case.  The user has an oldish mailto:-only record, the service introduces https: for those who can support.  The service can override the rua= thanks to step 8 of Section 7.1, Verifying External Destinations:

    8.  If a "rua" or "ruf" tag is thus discovered, replace the
        corresponding value extracted from the domain's DMARC policy
        record with the one found in this record.  This permits the
        Report Receiver to override the report destination.  However, to
        prevent loops or indirect abuse, the overriding URI MUST use the
        same destination host from the first step.

So we have:

at _dmarc.example.com:
"v=DMARC1; p=none; rua=mailto:[email-masked], mailto:[email-masked];"

at example.com._report._dmarc.service.example the verification record can specify a preferred reporting address:

"v=DMARC1; ruap=https://service.example/report/; rua=mailto:[email-masked];"

(Question: is it necessary to also specify rua= if it is unchanged?)

or it can use OR- syntax:

"v=DMARC1; rua=mailto:[email-masked], OR-https://service.example/report/;"

IMHO, both methods are valid and equally well interoperable.  We should choose the one that can be more easily and clearly specified.

For OR-, it is an advantage to be able to keep step 8 above unchanged.  OTOH, the concept of pseudo-scheme requires a new paragraph to be explained.  Perhaps we should provide tentative text, rather than examples?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 20 Jan 2021 14:19:23 -0500

On Wed, 20 Jan 2021, Alessandro Vesely wrote:
> "v=DMARC1; p=none; rf=afrf; 
> rua=mailto:[email-masked],https://dmreport.abuse.net/dmreport/; 
> ruf=mailto:[email-masked]"

Whaddaya mean fluffy?  Try a PUT or POST to that URI and it'll work.

> It is not underspecified.  It specifies the /mailto:/ scheme.  ...

Early drafts had an http PUT with some error that would have prevented it 
from working.  It was removed before 7489 was published.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 11:28:24 -0800

A little off topic, but is there any normative text in DMARC about the 
authenticity of the reporting? It seems like there ought to be normative 
text that the report should have a valid DKIM signature from the domain 
reporting. I'm not sure how you'd go about doing that with HTTPS though 
since client certs are essentially nil, and the normal way to do 
authentication is by creating an account.

Mike

On 1/20/21 11:19 AM, John R Levine wrote:
> Early drafts had an http PUT with some error that would have prevented 
> it from working.  It was removed before 7489 was published.
>
> Regards,

---

From: "John Levine" <[email-masked]>
Date: 20 Jan 2021 16:37:42 -0500

In article <[email-masked]> you write:
>authenticity of the reporting?

See section 7.2.

 It seems like there ought to be normative 
>reporting. 

I've been getting DMARC reports for nearly a decade and do not ever
remember getting one that looked fake. What would be the point? I
don't see this as a problem that needs solving.

It's a good idea for your reports to be aligned but only to prevent
useless reports and the failure loops that some people were
complaining about.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 13:51:27 -0800

>> authenticity of the reporting?

Sorry, I'm not seeing it.

> don't see this as a problem that needs solving.
What could possibly go wrong has an extremely poor track record. In the 
case of email it's an easy fix.

Mike

---

From: Steven M Jones <[email-masked]>
Date: Wed, 20 Jan 2021 15:10:14 -0800

> pre-holidays and has lain fallow since the end of 2020...

Prompted me to read from the start of the thread through:

> Whaddaya mean fluffy?  Try a PUT or POST to that URI and it'll work.

I think we should specify HTTPS URIs, and following 7489 section 12.6
"Secure Protocols" and current practices, HTTP should not be
specified/permitted.

However I don't yet see a compelling case for the OR- syntax or a
separate "ruap" tag. Duplicate reports to the same destination are not
the base case, and the bandwidth for unintended duplicates will likely
be much smaller than, say, per-message DNS tree walks being discussed
elsewhere. Report processors annoyed by receiving duplicates can work
with the domain owners in question, and if that doesn't work they can
withdraw their report authorization record.

--S.

---

From: Steven M Jones <[email-masked]>
Date: Wed, 20 Jan 2021 15:20:04 -0800

On 1/20/21 15:10, Steven M Jones wrote:
>
> Duplicate reports to the same destination are not
> the base case

I may be an idiot, or at least too quick to hit Send. Since nobody
implements https:// yet, what does the transition look like? Likely two
URIs to the same report processor, using each method.

But I suspect the specification can deal with preferring one method over
the other when both are present and the report generator supports both.

--S.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 16:05:53 -0800

> withdraw their report authorization record.

See this before spending too much time. It's probably better to just 
junk this enhancement.

https://trac.ietf.org/trac/dmarc/ticket/99

Mike

---

From: "John Levine" <[email-masked]>
Date: 20 Jan 2021 19:48:16 -0500

>URIs to the same report processor, using each method.

Right, that's the question. I suppose we could do some hack like
saying that you process the URIs from left to right, and if you
succesfully do an https report, skip all subsequent mailto's, or
subsequent mailto's in the same domain.

For the specific details of https reporting, here's the two options (both
already implemented):

A) Do an HTTPS POST to the URL with application/gzip contents. This is
similar to MTA-STS but has the disadvantage that you don't get the
filename of the report.

B) Do an HTTPS PUT to the URL appending the filename from sec 7.2.1.1,
also with application/gzip contents.

I mildly prefer B since the filename can be useful, and this makes it
idempotent, since two PUTs of the same filename only store it once.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Jan 2021 10:44:35 +0100

> Whaddaya mean fluffy?  Try a PUT or POST to that URI and it'll work.

Surely you don't expect a DMARC report generator to parse https: and scream out 
"Oh Gosh, here's what I've been hopelessly waiting for...".  For non-human 
parsers, it's fluff, no?

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Jan 2021 11:06:27 +0100

>> withdraw their report authorization record.

The point is that if you specify both mailto: and https:, a compliant report 
generator should send to both URLs.  OTOH, if you only specify https:, you are 
going to miss a lot of reports.

> See this before spending too much time. It's probably better to just junk this 
> enhancement.
> 

The proposed workaround implies sending base64, which is what https: is meant 
to avoid.  Your suggestion to use it as an authentication mechanism for https: 
sounds better.  You just need to add From: and DKIM-Signature: header fields, 
where the binary body is hashed as-is, that is, with no canonicalization.  It 
seems to require an easy software enhancement.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 21 Jan 2021 14:11:46 -0500

On Thu, 21 Jan 2021, Alessandro Vesely wrote:
> Surely you don't expect a DMARC report generator to parse https: and scream 
> out "Oh Gosh, here's what I've been hopelessly waiting for...".  For 
> non-human parsers, it's fluff, no?

I didn't know whether anyone had implemented the https reports in the 
early drafts of 7489.  Given that I haven't gotten any of them, apparently 
not.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2021 13:46:58 -0500

Here's a concrete proposal for https reporting:

In draft-ietf-dmarc-aggregate-reporting, in the transport section,
between Email and Other Methods add:

Https POST

The message is an XML file with GZIP compression, sent with an https POST message
to the given URI as media type application/gzip.
The data SHOULD contain the filename described in Email transport
above as the filename in the gzip header. The filename helps recipient
hosts recognize duplicate reports.

In draft-ietf-dmarc-dmarcbis section 6.3 under the rua tag, add:

If there is more than one URI in the value, the URIs are conceptually evaluated from
left to right and each report is delivered to each URI in turn.
If a delivery to an "https:" URI succeeds, any subsequent URIs that are not "https:" are ignored.
This allows a report recipient to prefer https reports while falling back to mailto reports.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sun, 24 Jan 2021 10:49:34 -0800

issue #99 needs to be addressed.

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2021 14:08:25 -0500

>issue #99 needs to be addressed.

I don't see any connection between issue 99 and this proposal.  This is not about failure reports.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sun, 24 Jan 2021 11:10:31 -0800

any reporting needs to be authenticated. if you're going to use http, 
you need to show how you're going to do that.

Mike

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2021 16:36:45 -0500

>you need to show how you're going to do that.

DMARC systems have been producing and consuming reports for a decade
without authentication, without any problems I am aware of other than
the occasional failure report loop, so we have practical experience
telling us this assertion is not true.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sun, 24 Jan 2021 13:41:40 -0800

> telling us this assertion is not true.
"That i'm aware of" doesn't count for anything in the security realm. If 
this document intends to be standards track the default security posture 
is that everything needs authentication. Good luck getting it through 
the IESG handwaving the problem away. At least with mail a little 
normative texts fixes the problem. That won't be the case for http.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 20:51:43 +0100

> This allows a report recipient to prefer https reports while falling back to mailto reports.

Good!  That's much better than any other idea we've been discussing.

Say an external URI overrides a mailto:"u" with a pair https:,mailto: and the 
https: succeeds.  Are mailto: URIs following "u" to be ignored?  Answering yes 
eases the job of a report generator, as it is enough to produce a report and a 
verified list of URIs.  Answering no may seem to ease the composition of DMARC 
records; otherwise one has to pay attention to put external URIs toward the 
end.  Some examples are needed anyway.

You'll have to revert the order in your DMARC record.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 20:53:54 +0100

> issue #99 needs to be addressed.

Won't we put a DKIM-Signature: in the http: header?

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 12:07:01 -0800

> Won't we put a DKIM-Signature: in the http: header?
I don't know. That would need to be specified. To me it sounds like a 
good reason to not try to specify http especially if there doesn't seem 
to be any clear desire for it.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 21:10:05 +0100

On Mon 25/Jan/2021 21:07:01 +0100 Michael Thomas wrote:
> I don't know. That would need to be specified. To me it sounds like a good 
> reason to not try to specify http especially if there doesn't seem to be any 
> clear desire for it.

Yes, it needs a spec.  It doesn't seem to be overly difficult.

If we put authentication at SHOULD, the missing spec is a good reason to skip 
signing.  Meanwhile we can try https:.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2021 15:44:22 -0500

>Won't we put a DKIM-Signature: in the http: header?

No, there's no spec for signing an http transaction.

If you want a client domain identity, It's easy enough to permit a
client SSL certificate, but as I have pointed out a few times, since
there are no recipient domains in an aggregate report, they don't
provide anything useful to link to.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2021 16:22:25 -0500

>Yes, it needs a spec.  It doesn't seem to be overly difficult.

Sheesh.  That isn't mission creep, it's mission gallop.

If you want a domain identity (even though in this case it provides
nothing useful), what's wrong with a client cert? They exist, they
work, they have software support everywhere.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2021 10:03:08 +0100

> Sheesh.  That isn't mission creep, it's mission gallop.

The spec can be commissioned to a narrowly focused WG (like dcrup).

MIME provides for a binary Content-Transfer-Encoding, albeit unused.  To sign a 
message thus (un)encoded, it is unreal to try and apply a line-oriented 
canonicalization.  The new spec should just introduce a "binary" 
canonicalization, which can only be used for the body.  From a software POV, it 
is a trivial update, as it's enough to hash the data as-is.

With that addition, DKIM can be used with HTTP transport, which is an 
interesting point per se.  Meanwhile we can specify that https: SHOULD be DKIM 
signed.

> work, they have software support everywhere.

Even if you can deduce a From: email address after the Subject Alt Name, you 
cannot reliably associate it to an organizational domain.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 26 Jan 2021 12:16:37 -0500

> The spec can be commissioned to a narrowly focused WG (like dcrup).

Really, no.  It's something we might think about on its own merits some 
other time, but its absurd to try to do it as a detour from DMARC.

> cannot reliably associate it to an organizational domain.

Sorry, that makes no sense at all.  The cert has a domain name, or a bunch 
of domain names.  You can do exactly as much or as little with those 
domain names as you can with the domain in an e-mail From: header.  Keep 
in mind, of course, that none of those domains have any connection at all 
with the contents of an aggregate report, no matter how it is delivered.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Jan 2021 09:23:35 -0800

> other time, but its absurd to try to do it as a detour from DMARC.

+1.  I don't see why we wouldn't just recharter this group (if that would
even be necessary) to do it.  The right audience is already here.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2021 18:27:05 +0100

> even be necessary) to do it.  The right audience is already here.

Doing it now might overload the WG.  If DKIM for binary has its own merit, we 
can just hypothesize we'll do.  Meanwhile we can mention it and suggest to use 
it for https: when it comes, if ever.  After all, that's what RFC 2045 does 
with "binary".

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 09:28:33 -0800

On 1/26/21 9:16 AM, John R Levine wrote:
>
>> Even if you can deduce a From: email address after the Subject Alt 
>> Name, you cannot reliably associate it to an organizational domain.
>
> Sorry, that makes no sense at all.  The cert has a domain name, or a 
> bunch of domain names.  You can do exactly as much or as little with 
> those domain names as you can with the domain in an e-mail From: 
> header.  Keep in mind, of course, that none of those domains have any 
> connection at all with the contents of an aggregate report, no matter 
> how it is delivered.
>

Use of client certs is a non-starter. The use of http here is 
problematic and getting more so. This entire issue should just be junked.

Mike

---

From: "John R Levine" <[email-masked]>
Date: 26 Jan 2021 12:37:56 -0500

> can just hypothesize we'll do.  Meanwhile we can mention it and suggest to 
> use it for https: when it comes, if ever.  After all, that's what RFC 2045 
> does with "binary".

Since client certificates exist and http DKIM signatures do not, that 
doesn't sound like a great plan.

Regards,