On Sun, Sep 16, 2018 at 10:42:26PM +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 > > > > > > > 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.
Whether or not it should be disallowed is probably a function of the severity of the XSS risk (which I don't have a good picture of right now) -- as I attempted to note in my ballot text, the token is only created by virtue of the account key holder's explicit request, which could itself be seen as an authorizing action. The echoing of the token by the HTTP server serves to confirm possession of the domain name, more than the specific authorization, in that worldview. > 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. Agreed that the text could be more clear. In particular, right now I think that the text about "participating in the creation" is inaccurate. -Benjamin _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
