I suspect that the guessable account numbers is something the LE folks will eventually regret for one reason or another.
It’s poor security design to make something public and/or guessable if it doesn’t need to be. -Tim From: Acme <acme-boun...@ietf.org> On Behalf Of Richard Barnes Sent: Tuesday, October 9, 2018 8:19 PM To: Jacob Hoffman-Andrews <j...@eff.org> Cc: IETF ACME <acme@ietf.org> Subject: Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462) You seem to be trying to approach this point-by-point.. What Adam and I have been saying is that randomizing everything, you don't have to do the analysis case by case. That's why that's the desired recommendation -- it's conservative. If you want to do the analysis, go ahead. The URL plan is 100% up to the server operator. But the recommendation in the spec should be the conservative one. --Richard On Tue, Oct 9, 2018 at 7:49 PM Jacob Hoffman-Andrews <j...@eff.org <mailto:j...@eff.org> > wrote: I'll revise this to include examples from the other URLs. One of my goals is to switch away from the "counting accounts" or "counting authzs" examples (which I think we can't effectively mitigate) to more specific examples of correlations. However, I think I can make that point with examples from across all the different resource types. On 10/09/2018 12:27 PM, Richard Barnes wrote: Thanks for the PR. My only issue is with the changes in there that slim down the example. ISTM that we should be encouraging unguessable URLs as widely as possible; guessable URLs should be a justified exception (as you noted in your description of what LE does). If you could slim this down to just killing the "Capability URL" reference, I would be +1 On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews <j...@eff.org <mailto:j...@eff.org> > wrote: On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote: > Also, I would add a caveat that this type of URL design is only > necessary for properties that the CA considers secret. For instance, > Let's Encrypt does not consider its number of accounts secret, and > assigns serially incrementing IDs to account URLs. > > I'll send a PR later today tweaking this section. Here's a PR improving the correlations section of security concerns: https://github.com/ietf-wg-acme/acme/pull/463 _______________________________________________ Acme mailing list Acme@ietf.org <mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
