Sorry if I pulled the trigger on that one a bit early. Happy to revise, as always.
I think there was pretty feeling in the room at the IETF meeting that Content-Type checking was not doing much. Are we aware of any actual scenarios where untrusted entities can write to .well-known directories? Because my base inclination is to encourage web admins to protect against file dropping attacks by, well, not allowing users to drop files in arbitrary locations. --Richard On Thu, Nov 12, 2015 at 7:44 PM, Peter Eckersley <[email protected]> wrote: > https://github.com/ietf-wg-acme/acme/pull/40 was just merged, but we > didn't actually get consensus that dropping Content-Type restrictions > altogether was a good idea. > > The options are: > > 0.keep the old spec (Content-Type application/jose+json, no file > extensions allowed) > > 1 keep the application/jose+json Content-Type requirement, add or allow > a .jose file extension in the challenge > > 2 switch to text/plain but add or allow a .txt file extension > > 3 drop all Content-Type requirements (PR #40) > > 4 leave the matter totally up to the CA (it can tell the client if > there's a Content-Type requirement, and if so what it is) > > I believe the purpose of the Content-Type requirement was to mitigate > against file-dropping attacks in web applications. Everyone agrees that > option 0 is a bad spot on the security/usability tradeoff. But is 3 the > best answer? Can we keep some anti-file-dropping protection without > making manual authentication a pain? Or are the two inherently the same > thing? > > > -- > Peter Eckersley [email protected] > Chief Computer Scientist Tel +1 415 436 9333 x131 > Electronic Frontier Foundation Fax +1 415 436 9993 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
