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

[Felix Fontein <[e-mail]>]

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
> > > > > > thumbprint> 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.)

That would work. However, I'm not sure whether this should really be
disallowed. I also understand the text from draft-14 as you do, but I
since this incorporates the account key hash, it doesn't validate for
challenges coming from other ACME accounts.

Also, there has been a proposal
(https://github.com/ietf-wg-acme/acme/issues/393) to allow something
similar for DNS validation (as dns-02), which explicitly mentions this
automation. Since nobody responded that such an automation is unwanted,
my assumption is that this automation is a feature and not a bug. It
would be nice if this would be more clear from the text, though.

Cheers,
Felix