Re: [Acme] Content-Type and file extensions for HTTP01 challenges

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 <pde@eff.org> 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                            pde@eff.org
> Chief Computer Scientist          Tel  +1 415 436 9333 x131
> Electronic Frontier Foundation    Fax  +1 415 436 9993
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme