Hi Zach, > This seems incongruous. If the token must be kept secret an attacker, it > should not be served via an unauthenticated channel.
I agree the wording makes it incongruous, I was caught up on this the other week until it was clarified for me by Jacob. The token is random not to prevent a guessing attack but to prevent the implementation of a server that can automatically reply to challenges without being a party to the authorization creation (e.g. knowing the token). It's OK for the token to be served via an unauthenticated channel, it just can't be predictable. I took a crack at rewording this in https://github.com/ietf-wg-acme/acme/pull/284 - Hopefully if I'm completely off-base someone can correct it to be accurate & understandable. On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd <[email protected]> wrote: > The following feedback is based on 8010a31 (current HEAD of master). > > Section 6.2, Request Authentication, states "Note that authentication via > signed JWS request bodies implies that GET requests are not authenticated. > Servers MUST NOT respond to GET requests for resources that might be > considered sensitive. Account resources are the only sensitive resources > defined in this specification." > > Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and > 8.4, DNS, each describe a GET request and specify a "token" value which > "MUST have at least 128 bits of entropy, in order to prevent an attacker > from guessing it." > > This seems incongruous. If the token must be kept secret an attacker, it > should not be served via an unauthenticated channel. > > Assuming secrecy of the token is not important, I would propose removing > the entropy requirement and including some discussion of the token in > Section 10, Security Considerations. > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
