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

Bryan Livingston <bryanlivingston@gmail.com> Fri, 13 November 2015 00:57 UTC

Return-Path: <bryanlivingston@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B636D1B3B76 for <acme@ietfa.amsl.com>; Thu, 12 Nov 2015 16:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjuNvWWdet-z for <acme@ietfa.amsl.com>; Thu, 12 Nov 2015 16:57:38 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44071B3B74 for <acme@ietf.org>; Thu, 12 Nov 2015 16:57:36 -0800 (PST)
Received: by lbblt2 with SMTP id lt2so45559711lbb.3 for <acme@ietf.org>; Thu, 12 Nov 2015 16:57:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MR9z0+36RGlxoXC+K3siMpjLVBncHrNn9L2Yzn3YyuU=; b=Spx68bYtZJc7OsTld60tJlpg+tDEVWIgup/f/oEEL4GOuwjN4PUfZqy0oHG86gMCU+ QCsDphMcEi5QY8lXyWUBF3Ehf0gS21Hsi/rYvQfzu2kZgr1Ly18Jvs8QGlriJYYzH6JQ QjYvbIZK0AVRtUXteNMPOY2vzYGC5laKKu2CQSe7FOY9rdhQMd9wNriNZWEWkTChVlnC QbYdgir8eP5FKnbtpci8UKYy8tmp+IDt9jkR9AkP10LtkAVOOwY59744/OlCT5HfqrZ/ sXHZrv6y+/ul0ISKeezBATdNnnlUptOI4YJudDZqC2WTNRzFNXu5ER14j+VyfyiVgRhE gllQ==
MIME-Version: 1.0
X-Received: by 10.112.149.5 with SMTP id tw5mr8837142lbb.50.1447376254811; Thu, 12 Nov 2015 16:57:34 -0800 (PST)
Received: by 10.25.37.19 with HTTP; Thu, 12 Nov 2015 16:57:34 -0800 (PST)
In-Reply-To: <20151113004436.GB18430@eff.org>
References: <20151113004436.GB18430@eff.org>
Date: Thu, 12 Nov 2015 17:57:34 -0700
Message-ID: <CABsBmKMv0fJ5Sf4p3UCWFpnhaBsWgrWtHC9SxEPAZVv2cYHArQ@mail.gmail.com>
From: Bryan Livingston <bryanlivingston@gmail.com>
To: Peter Eckersley <pde@eff.org>
Content-Type: multipart/related; boundary="047d7b3434d28672080524618bcc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/AtiF2Cnkz7-_oJomGrvk1PrO2ZU>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Content-Type and file extensions for HTTP01 challenges
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 00:57:40 -0000

I'd like to advocate for 2 or 3 with a .txt extension added as it will just
work in all known default IIS configurations.

On IIS if there's no mime type (and there's not a mime type for
extensionless files by default) then no file can be served. So adding a
web.config file is manditory for us.

But that can still cause problems. Here's a screenshot of what happens of
the user happened to already have an extensionless mime type set on their
server.

[image: Inline image 1]

On top of that there's still the problem of the handler mappings, which is
caused by ASP.net eating all the extensionless requests, even if there's a
static file present. The fix for that is described here:
http://stackoverflow.com/questions/11473632/extensionless-image-file-not-visible-in-iis7-5

On Thu, Nov 12, 2015 at 5: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
>