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 10:41:42AM -0500, Benjamin Kaduk wrote:
> 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.
> 
> ?

Also, if we wanted to prevent this sort of dumb script, it seems like we
could have the ACME server do a 
GET /.well-known/acme-challenge/<hash-of-token>
instead of
GET /.well-known/acme-challenge/<token>

and expect the un-hashed token in the response body.  (Witih obvious
questions about explicit hash agility vs. hardcoding a hash per challenge
type.)

-Ben