On Sun, Dec 6, 2020 at 9:32 PM Owen Friel (ofriel) <ofr...@cisco.com> wrote:
> [ofriel] Are there any benefits or security advantages in #1 (client > giving server options) vs. #2 (server giving client options)? With #2, the > client does not have to explicitly divulge any information about its level > of domain control. The server gives the client a set of options, and the > client decides what to do. Obviously, if it fulfils the challenge against a > parent Authorized Domain Name, then it has implicitly indicated control > over that domain. > 🤷‍♂️ If there is a limit to the number of challenges, it seems it benefits from the client choosing/advertising. Until the challenge is complete, the server has to maintain state for (effectively) an unauthorized user, while in the client-advertise scenario, there’s no server state other than what the server chooses to use. Further, if we assume that say there are ten domain labels, but the server is only willing to maintain state for five (as a window), then it’s not clear how the client can request the server sends the first five rather than the last five. Having the client advertise its capabilities let’s the client choose the window, and if the server rejects all of them, the client at least can try again with a different window (e.g. the last five labels). I don’t know how compelling this is, but my assumption here is that because we’re discussing effectively DNS-01 challenges, the client is limited in its abilities, and so the client should indicate it’s capabilities, and minimize server state. Equally in this scenario, I think you're asking whether or not the client > should be able to indicate its capabilities to the ACME server, for > selecting appropriate challenges. If a client is using dns-01 and can only > modify subdomain.example.com, it doesn't benefit the client at all if the > server chooses to also allow example.com. The question is whether there's > a security risk in doing so; that is, should the client be able to > affirmatively restrict the server or does it not matter. > > > > [ofriel] Yes, that is exactly what I am getting at. Perhaps the question > #1 should be phrased more accurately something like: Does the client need a > mechanism to indicate to the server that it is capable of and authorized to > fulfil challenges against the requested subdomain FQDN, as well as some or > all of the parent Authorized Domain Names (potentially up to and including > the Base Domain Name). > > > > TBH I have no thought about the security risk of a client indicating to > the server that it has control over parent domains, potentially including > the Base Domain Name. What does the CA/B currently think about this? > I mean, right now there’s no rules on which party selects the Authorization Domain Name, when an ADN is allowed. The CA still has to validate the ADN against the rules. Having the client indicate minimizes CA processing before validation; each of the advertised ADNs can really be treated as independent FQDNs (that is, largely opaquely), and only after validation of the challenge does the CA do any processing on the domain label, to ensure it’s an ADN for the (originally requested) FQDN. That’s why my slight preference was to have the client advertise. Processing after validation seemed preferable to processing prior to validation, and it also seemed useful to let the client advertise capabilities directly to let the server reduce any stored state. However, I can equally imagine an asinine implementation of client-advertise that requests a cert for “www.example.com” but let’s the client set the ADN as “ example.net” and, post-validation of example.net, fails to check that “ example.net” matches “example.com”. Or does something equally silly like allowing “prefix.example” to authorize “not-actually-a-prefix.example”.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
