Subject: [dmarc-ietf] Section 12.2.2

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 9 Aug 2013 18:19:19 +0000

John Levine posted regarding using HTTP (see below) and this came up in the BOF as well. Perhaps we could have the discussion on the list and perhaps even have some conclusions for last call on the draft.

> 
> * Decide whether to remove section 12.2.2 since I don't think anyone has
> ever implemented and it's rather badly specified.  Every http POST I've ever
> seen has had an application/x-www-form-urlencoded or multipart/form-
> data body.  While there's nothing in the http spec that forbids other random
> multiparts, I wouldn't want to write it into a standards track document unless
> I was confident that web servers would do something reasonable.  Note that
> an http PUT means to replace whatever is at the URL with the body of the
> message, which is not what you want.
> POST makes more sense, but for a POST to work reliably you'd be much
> better off with the gzip file inside a multipart/form-data.  The Subject field it
> describes is also pretty dodgy since I don't know anyone who uses them with
> http, and would in any event be redundant with the filename in the form-
> data.  The section is also somwhat underspecified on the response side, since
> it gives no hint as to what http return codes might be returned and how a
> receiver should interpret them, e.g., if it gets a 302 should it really go re-post
> it somewhere else?  If it gets a 4xx should it keep sending subsequent
> reports?
>

---

From: Andreas Schulze <[email-masked]>
Date: Fri, 09 Aug 2013 21:55:57 +0200

Zitat von "MH Michael Hammer (5304)" <[email-masked]>:

> John Levine posted regarding using HTTP (see below) and this came up  
> in the BOF as well. Perhaps we could have the discussion on the list  
> and perhaps even have some conclusions for last call on the draft.

In my opinion the http transport has the disadvantage of total  
unauthenticated submission.
for smtp one can force the submission message has to be valid dkim signed.

On the other side there is no implementation.

John, which domain request aggregated reports via http?
Maybe an implementation using curl is really easy...

Andreas

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 9 Aug 2013 20:12:34 +0000

Andreas,

I'm not a fan of HTTP as a channel but recognize that it is in the spec and that there are issues with it. I just figure that seeing as it came up it is probably worth having the discussion and dealing with. Personally I would have no problems if this was dropped as a channel for the reports but, there it is.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Andreas Schulze
> Sent: Friday, August 09, 2013 3:56 PM
> To: [email-masked]
> Cc: John Levine
> Subject: Re: [dmarc-ietf] Section 12.2.2
> 
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "John R Levine" <[email-masked]>
Date: 9 Aug 2013 16:35:35 -0400

> for smtp one can force the submission message has to be valid dkim signed.

This objection makes no sense.  The usual complaint about http security is 
that there are too many authentication schemes, not too few, ranging from 
plain text 
http auth to TLS client certs to oAuth.

> Maybe an implementation using curl is really easy...

A quick review of the DMARC spec reveals that HTTP submission has been 
there for over a year.  Someone told me that someone somewhere sends http 
reports, although the current text is so underspecified that it's anyone's 
guess what they're actually doing.

If you want authentication, you can use https and look for a client 
certificate.  Since anyone sending reports is doing you a favor, it would 
be counterproductive to demand that they jump through authentication hoops 
to do so, and I've never understood the threat model.

Are you worried that someone will send you fake reports?  Why?  If they 
do, what damage will it cause?  How hard will it be to mitigate, and how 
does that cost compare to the cost of getting no reports at all from 
people who don't feel like following your authentication rules?

Finally, it's not hard to tell curl to do an http PUT with or without http 
auth or TLS client certs, although I expect that most people sending 
reports have written their report generator in something like python, so 
they'd use one of the existing http client libraries.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Andreas Schulze <[email-masked]>
Date: Fri, 09 Aug 2013 23:46:00 +0200

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

> This objection makes no sense.  The usual complaint about http  
> security is that there are too many authentication schemes, not too  
> few, ranging from plain text http auth to TLS client certs to oAuth.
of course there are authentication schemes for http.

> Are you worried that someone will send you fake reports?  Why?  If  
> they do, what damage will it cause?  How hard will it be to  
> mitigate, and how does that cost compare to the cost of getting no  
> reports at all from people who don't feel like following your  
> authentication rules?
If I think again about it, in both (http/smtp) cases the data must be received
before any kind of validation can occur.

 From this perspective there is really no difference between http and smtp.
So, sorry for my noise :-)

If nobody implemented http reporting yet
we should consider removing it from the spec...

Andreas