Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Sun, Sep 16, 2018 at 05:35:37PM +0200, Felix Fontein wrote:
> Hi,
> 
> > > >    [...] Secondly, the entropy requirement
> > > >    prevents ACME clients from implementing a "naive" validation
> > > > server that automatically replies to challenges without
> > > > participating in the creation of the initial authorization
> > > > request.
> > > >
> > > > IMPORTANT: I'm not sure I see how this applies to the HTTP
> > > > mechanism -- couldn't you write a script to reply
> > > > to .well-known/acme-challenge/<foo> with <foo>.<key thumbprint>
> > > > for a fixed key thumbprint?  The validation server would ned to
> > > > know about the ACME account in question, but not about any
> > > > individual authorization request.  
> > > 
> > > It would also need to know the <foo> value, which is not provided
> > > in the validation request specifically to avoid this.  
> > 
> > As I said above, "[w]ell now I'm really confused."  In the example
> > HTTP challenge exchange (duplicated here):
> > 
> > GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0
> > Host: example.org
> > 
> > HTTP/1.1 200 OK
> > Content-Type: application/octet-stream
> > 
> > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI
> > 
> > Doesn't the path in the GET include the <foo>?
> 
> Yes, and some people are already using this to add a generic
> authorization replier (which needs the thumbprint of the account key).
> For example, the acme.sh client supports this "stateless mode" (as it
> is called there):
> https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode

Okay, that matches up with my understanding and maybe un-confuses me.

But does this state of affairs nullify the text in the -14 about:

   [...] the entropy requirement
   prevents ACME clients from implementing a "naive" validation server
   that automatically replies to challenges without participating in the
   creation of the initial authorization request.

?

-Benjamin

> (There currently is also a discussion in the Let's Encrypt community
> forum about this, see
> https://community.letsencrypt.org/t/xss-via-acme-implementations/72295;
> this is because some implementations do not restrict the allowed input
> and thus allow XSS attacks, as described here:
> https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/)
> 
> Cheers,
> Felix
> 
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme