> > I think Daniel's change at https://github.com/ietf-wg- > acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it > could use a few extra sentences explaining it in security considerations.
I will take a crack at amending this PR with a few sentences in the security considerations section. On Thu, Mar 23, 2017 at 3:24 PM, Jacob Hoffman-Andrews <[email protected]> wrote: > Yep, I think there are two ways of thinking about this, though it's > effectively a single problem: > > 1. Prevent attackers from tricking a validation endpoint into serving a > valid challenge response. > 2. Prevent ACME clients from implementing a "naive" validation method > that would make (1) trivial. > > I think Daniel's change at https://github.com/ietf-wg- > acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it > could use a few extra sentences explaining it in security considerations. > > > On 03/23/2017 10:34 AM, Zach Shepherd wrote: > > It seems like the goal of this is to ensure that the ACME client is not > able to control (or, perhaps, even influence) the choice of token and > requiring > that the token be sufficiently random is one way to achieve this. This > prevents an attacker from "tricking" the ACME server into using a > verification performed by the owner of an identifier as proof that the > attacker controls the identifier. > > Is this accurate? If so, it seems like some version of this explanation > should be included in the Security Considerations section. > > ------------------------------ > *From:* Daniel McCarney <[email protected]> <[email protected]> > *Sent:* Wednesday, March 22, 2017 10:30 AM > *To:* Zach Shepherd > *Cc:* [email protected] > *Subject:* Re: [Acme] Entropy requirement for challenge token > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_284&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=-wsi8BGqTPZ2pJgly5Zek9hlFtTALxFUHGs27TMvg1s&s=_Tra8Ezjve5vo2ooWGFKPe2BHELn3kzY0WMkDBK3nLw&e=> > - 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=-wsi8BGqTPZ2pJgly5Zek9hlFtTALxFUHGs27TMvg1s&s=aKavTfL1kLx6wAvRKcSMGq_FwERH4NCW4EQ--ipFWts&e=> >> >> > > > _______________________________________________ > Acme mailing [email protected]https://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
