Subject: Re: [dmarc-ietf] Section 12.2.2

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 1 Dec 2013 11:08:03 -0800

On Sat, Nov 30, 2013 at 11:08 PM, John R Levine <[email-masked]> wrote:

> If nobody implemented http reporting yet
>>> we should consider removing it from the spec...
>>>
>>
>> Any other opinions on this point?
>>
>
> The current spec is too messed up to allow interoperable implementations.
> (PUT and POST are not the same thing at all.)
>
> For large reports, http PUT is a much better way to deliver them than
> mail, since it's basically just a file upload to the target's web server,
> no base64 encoding or decoding needed, and no extra copies filling up mail
> spools.  It's easily made snoop and spoof resistant by using https, and
> it's easy to program because all of the usual http libraries support it.
>
> If any of the usual suspects are interested, I can tell you how to fix the
> spec.  It's not very hard, change it to be only PUT, and specify how to
> construct the PUT filename for each report.
>

Sure, can you send specific "change this to that" sets?  I'll change it in
the working copy.

Thanks,
-MSK

---

From: John R Levine <[email-masked]>
Date: Sun, 1 Dec 2013 15:51:26 -0500 (EST)

> Sure, can you send specific "change this to that" sets?  I'll change it in

Replace section 11.2.2, which I gather is now 12.2.2, with this:

11.2.2.  HTTP

    Where an "http" or "https" method is requested in a Domain Owner's
    URI list, the Mail Receiver delivers the the data using a PUT http
    request.  The URI for the PUT request is the URI from the list
    concatenated with a filename constructed as described in the previous
    section.  The extension in the filename MUST be .xml.  The filename
    SHOULD contain a unique-id that is difficult to guess.  For example,
    if the URI in the list were "http://example.com/dmarc-report/" the URI
    for the PUT request might be

http://example.com/dmarc-report/mail.receiver.example!example.com!1013662812!1013749130!!~q!}{..xml

    The Mail Receiver MUST send the Appendix C data as a text/xml media
    type and SHOULD use the gzip content-coding.

I checked that the http and URI specs specifically allow exclamation points.

The semantics of a PUT is that the URI is the name of a file that's being 
uploaded.  If you do two puts with the same URI, the second one replaces 
the first one, so don't do that unless the first one was a mistake.  Bad 
guys can send fake reports, which they can also do through e-mail, but 
they can't stomp on real reports unless they know the filename, which 
seems unlikely with a unique-id.

R's,
John

PS: The rule for unique-id imports "token" from MIME, which allows 
exclamation points and periods tildes and and curly braces.  Is that 
really what you want?

---

From: Franck Martin <[email-masked]>
Date: Sun, 1 Dec 2013 13:44:00 -0800

On Dec 1, 2013, at 12:51 PM, John R Levine <[email-masked]> wrote:

> The semantics of a PUT is that the URI is the name of a file that's being uploaded.  If you do two puts with the same URI, the second one replaces the first one, so don't do that unless the first one was a mistake.  Bad guys can send fake reports, which they can also do through e-mail, but they can't stomp on real reports unless they know the filename, which seems unlikely with a unique-id.
> 

For email, we do recommend, that the report be sufficiently authenticated (pass DMARC). What kind of protection we could provide for http? Client certificate, which would require https only? Add some sort of DNS record to say these reports come only from these IPs?

I think we should drop http, anyhow, and mandate https. This is fashionable lately.

---

From: John R Levine <[email-masked]>
Date: Sun, 1 Dec 2013 17:15:10 -0500 (EST)

> For email, we do recommend, that the report be sufficiently 
> authenticated (pass DMARC). What kind of protection we could provide for 
> http? Client certificate, which would require https only? Add some sort 
> of DNS record to say these reports come only from these IPs?

Client certificates work now, anything else requires moving parts that 
don't exist yet.

11.2.2.  HTTP

   The Mail Receiver MUST send the Appendix C data as a text/xml media
   type and SHOULD use gzip content-coding.  If the URI has an "https"
   method the Mail Receiver SHOULD present a client certificate that
   includes the domain in its report (in the example above,
   mail.receiver.example) to authenticate itself.

R's,
John

---

From: Andreas Schulze <[email-masked]>
Date: Mon, 02 Dec 2013 08:07:58 +0100

Zitat von John R Levine <[email-masked]>:

>> authenticated (pass DMARC). What kind of protection we could  
>> provide for http? Client certificate, which would require https  
>> only? Add some sort of DNS record to say these reports come only  
>> from these IPs?
>
> Client certificates work now, anything else requires moving parts  
> that don't exist yet.

yes, the requirement for authentication could be satisfied by client  
certificates.
But this introduces additional complexity. I'm sure, I would get less  
more reports
if I would request them https.

So it could be an second way a reporter could send *full* reports if  
mailto: limit it's size.

Andreas