Re: [Acme] acme subdomains open items
Owen Friel (ofriel) wrote:
> The draft as is does not preclude http-01 challenges, but I agree that
> the dns-01 challenge is more applicable.
I'm gonna pick on this part only.
An http-01 challenge shows that the client controls the web resource that is
named.
It does nothing at all about control of the DNS. We don't know anything
about the client's control over the DNS, about any other names in the DNS.
When we do a dns-01 challenge for a specific name, we mostly prove exactly
the same thing: that the client can direct traffic to that name to a place
that it could potentially control.
{Well, the presence of CNAMEs (and DNAMEs) blurs this a bit}
If we do a dns-01 challenge for foo.example, then there is an assumption
in the challenge that we control the DNS for foo.example, and therefore
could put any.thing.foo.example into the DNS and control that.
Really, it doesn't quite prove that, it proves that we can update
_acme-challenge.foo.example, and that could be the only thing we
can actually control.
We might want to think about whether the authorization phase for
a subdomain challenge might need to show control over more bits than just that.
For instance, we could demand proof of
_acme-challenge.ran.dom.token.foo.example.
Perhaps even that we can insert A or records at that spot too.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
Ryan, Michael, I think you are both actually in agreement and both arguing for exactly the same thing. I think I agree that it makes more sense if the client advertises its authorized set of ADNs. e.g. if a client needs a cert or pre-authz for foo1.foo2.bar.example.com, it can offer anything from 1 to 4 different ADNs that it is capable of fulfilling. The draft as is does not preclude http-01 challenges, but I agree that the dns-01 challenge is more applicable. Does it make sense for the client to also be able to advertise the types of challenges it can fulfil? e.g. only advertise support for dns-01 but not http-01; or advertise support for both. RFC 8555 does not support this, nor does version -03 of this draft. If a client is advertising multiple ADNs it can authorize, should the supported challenge type be per ADN? e.g. dns-01 and http-01 for foo1.foo2.bar.example.com but only dns-01 for example.com? Is this flexibility in any way useful, or just likely to lead to confusion and implementation bugs? For sure, the way the draft is currently written, if a client places an order for a subdomain, and the server issues a single challenge for a parent ADN (which could be the BDN/Base Domain Name), then this will result in frequent failures as the client is not authorized to control the parent ADN/BDN. From: Ryan Sleevi Sent: 10 December 2020 03:51 To: Michael Richardson Cc: Ryan Sleevi ; Owen Friel (ofriel) ; Felipe Gasper ; acme@ietf.org Subject: Re: [Acme] acme subdomains open items On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson mailto:m...@sandelman.ca>> wrote: > Alas, I'm equally at a loss to understand what you're asking here, as I > can't make much sense of your question? dns-01 challenges for bar.bar.foo.example do not have to show control over foo.example. Yet, you seem to think that they do. Thanks for being clear! To respond: No, I don't. I'm highlighting that for a requested identifier of "baz.bar.foo.example", the CA is permitted to challenge for "bar.foo.example" or "foo.example". Indeed, some CAs, by default, will only challenge for "foo.example", despite that being a parent of the requested domain, because they want to reduce the effort involved to issue other certificates to that user. Now, I never said a CA "has" to, but it's certainly true that a number of CAs do, in fact, require this as their standard operating procedure, and my understanding is that this proposal was specifically about enabling such cases within ACME. That is, more generally, making a clear and well-lit path where the domain used in the authorization does not match the domain in the certificate. Is that an unreasonable understanding? It seems directly supported in the text of the draft, Section 5.4, https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , example 1. >> The client does not demonstrate control over lex.example using dns-01 when >> it >> asks for so.me.comp.lex.example. > Is that not literally what this draft is proposing (e.g. > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ? It demonstrates control (during the authorization) for lex.example, which allows it to fullfil orders for so.me.comp.lex.example. Your line of questioning implies you think the reverse. 5.2 clearly shows authorization for example.org<http://example.org>, followed by an order for sub.example.com<http://sub.example.com> I am again at a loss for what you mean here / what you are attributing to me. Equally, I'm hoping that the "example.org<http://example.org>" / "sub.example.com<http://sub.example.com>", as I cannot make any sense of what you said otherwise. As to your statement about me thinking the reverse, I'm hoping you can perhaps rephrase the following paragraph in Section 5.1: It may make sense to use the ACME pre-authorization flow for the subdomain use case, **however, that is an operator implementation and deployment decision.** With the ACME pre-authorization flow, the client could pre-authorize for the parent domain once, and then issue multiple newOrder requests for certificates for multiple subdomains. With the section in emphasis (**), it seems clear that this draft is not prescriptive as to whether the example in Section 5.2 (the "pre-authorization flow") needs to be required. To try to be clearer, since it seems you and I may be talking past each other and have been for some time, I'm considering the following flow: - POST /newOrder "so.me.comp.lex.example" Where the server needs to determine the appropriate set of authorizations to return for this case and the set of challenges within those authorizations. Again, this seems directly supported by Section 5.4 of the draft, https://tools.ietf.org/html/draft-friel-acm
Re: [Acme] acme subdomains open items
On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson wrote: > > Alas, I'm equally at a loss to understand what you're asking here, > as I > > can't make much sense of your question? > > dns-01 challenges for bar.bar.foo.example do not have to show control over > foo.example. > Yet, you seem to think that they do. > Thanks for being clear! To respond: No, I don't. I'm highlighting that for a requested identifier of "baz.bar.foo.example", the CA is permitted to challenge for "bar.foo.example" or "foo.example". Indeed, some CAs, by default, will *only* challenge for "foo.example", despite that being a parent of the requested domain, because they want to reduce the effort involved to issue other certificates to that user. Now, I never said a CA "has" to, but it's certainly true that a number of CAs do, in fact, require this as their standard operating procedure, and my understanding is that this proposal was specifically about enabling such cases within ACME. That is, more generally, making a clear and well-lit path where the domain used in the authorization does not match the domain in the certificate. Is that an unreasonable understanding? It seems directly supported in the text of the draft, Section 5.4, https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , example 1. > > >> The client does not demonstrate control over lex.example using > dns-01 when > >> it > >> asks for so.me.comp.lex.example. > > > Is that not literally what this draft is proposing (e.g. > > > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ? > > It demonstrates control (during the authorization) for lex.example, which > allows it to fullfil orders for so.me.comp.lex.example. > > Your line of questioning implies you think the reverse. > 5.2 clearly shows authorization for example.org, followed by an order for > sub.example.com I am again at a loss for what you mean here / what you are attributing to me. Equally, I'm hoping that the "example.org" / "sub.example.com", as I cannot make any sense of what you said otherwise. As to your statement about me thinking the reverse, I'm hoping you can perhaps rephrase the following paragraph in Section 5.1: It may make sense to use the ACME pre-authorization flow for the subdomain use case, **however, that is an operator implementation and deployment decision.** With the ACME pre-authorization flow, the client could pre-authorize for the parent domain once, and then issue multiple newOrder requests for certificates for multiple subdomains. With the section in emphasis (**), it seems clear that this draft is not prescriptive as to whether the example in Section 5.2 (the "pre-authorization flow") needs to be required. To try to be clearer, since it seems you and I may be talking past each other and have been for some time, I'm considering the following flow: - POST /newOrder "so.me.comp.lex.example" Where the server needs to determine the appropriate set of authorizations to return for this case and the set of challenges within those authorizations. Again, this seems directly supported by Section 5.4 of the draft, https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , example 1. > > In the pre-auth flow, the client affirmatively requests > "lex.example" (In > > the illustration here, "example.org"), in order to authorize > > "so.me.comp.lex.example" (in the illustration here, "sub.example.org > "). > > That is, the client explicitly declares their naming scope. > > > However, in the pre-auth flow, you have to know that the client will > want > > to be able to /newOrder for "sub.example.org" (as Step 2 in the > > illustration), since you shouldn't return http-01 authorizations in > Step 1 > > for this case. > > how are http-01 authorizations involved? > The client asks for dns-01 authorizations. Can you point me to the text in the draft you're using to support this statement? As far as I can tell, there's nothing in the draft to indicate that the client asks for dns-01 authorizations. Further, there's nothing as far as I can tell that prohibits, restricts, or even allows a CA to indicate that an http-01 authorization would not be allowed. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
Ryan Sleevi wrote: >> Ryan Sleevi wrote: >> >> The client has control over lex.example, but and can prove it with >> dns-01 >> >> TXT >> >> record placed at _acme-challenge.lex.example. Why does it matter >> whether >> >> it >> >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. >> >> or an.other.comp.lex.example?? >> >> >> > The mistake you’ve made here is assuming the client has control over >> > lex.example, and thus all subdomains. The point of all of this is >> that is >> > an unrealistic assumption: the client may only have control over the >> DNS >> > zone at so.me.comp.lex.example or they might have control at the >> > me.comp.lex.example, but no control at comp.lex.example. >> >> I don't understand. >> If the client doesn't control lex.example, then why would it expect to get >> any kind of control of that? >> Same as without subdomains. >> > Alas, I'm equally at a loss to understand what you're asking here, as I > can't make much sense of your question? dns-01 challenges for bar.bar.foo.example do not have to show control over foo.example. Yet, you seem to think that they do. >> The client does not demonstrate control over lex.example using dns-01 when >> it >> asks for so.me.comp.lex.example. > Is that not literally what this draft is proposing (e.g. > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ? It demonstrates control (during the authorization) for lex.example, which allows it to fullfil orders for so.me.comp.lex.example. Your line of questioning implies you think the reverse. 5.2 clearly shows authorization for example.org, followed by an order for sub.example.com > In the pre-auth flow, the client affirmatively requests "lex.example" (In > the illustration here, "example.org"), in order to authorize > "so.me.comp.lex.example" (in the illustration here, "sub.example.org"). > That is, the client explicitly declares their naming scope. > However, in the pre-auth flow, you have to know that the client will want > to be able to /newOrder for "sub.example.org" (as Step 2 in the > illustration), since you shouldn't return http-01 authorizations in Step 1 > for this case. how are http-01 authorizations involved? The client asks for dns-01 authorizations. > The significant majority of CAs, for the majority of certificates issued by > these CAs, totally rely upon authorizing "lex.example" in order to issue > certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or > other). So I'm not sure what you mean by "does not demonstrate > control". I think that I have typoed above! :-) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
On Tue, Dec 8, 2020 at 4:33 PM Michael Richardson wrote: > > Ryan Sleevi wrote: > >> The client has control over lex.example, but and can prove it with > dns-01 > >> TXT > >> record placed at _acme-challenge.lex.example. Why does it matter > whether > >> it > >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. > >> or an.other.comp.lex.example?? > > > > The mistake you’ve made here is assuming the client has control over > > lex.example, and thus all subdomains. The point of all of this is > that is > > an unrealistic assumption: the client may only have control over the > DNS > > zone at so.me.comp.lex.example or they might have control at the > > me.comp.lex.example, but no control at comp.lex.example. > > I don't understand. > If the client doesn't control lex.example, then why would it expect to get > any kind of control of that? > Same as without subdomains. > Alas, I'm equally at a loss to understand what you're asking here, as I can't make much sense of your question? > > The existing approach with ACME assumes and expects that validation > will be > > done at the FQDN (this is an oversimplification, but the nuance here > isn’t > > as important). > > Yes, the FULLY-QUALIFIED. Not the public name. > dns-01 works just fine today for so.me.comp.lex.example. > > The client does not demonstrate control over lex.example using dns-01 when > it > asks for so.me.comp.lex.example. > Is that not literally what this draft is proposing (e.g. https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ? In the pre-auth flow, the client affirmatively requests "lex.example" (In the illustration here, "example.org"), in order to authorize "so.me.comp.lex.example" (in the illustration here, "sub.example.org"). That is, the client explicitly declares their naming scope. However, in the pre-auth flow, you have to know that the client will want to be able to /newOrder for "sub.example.org" (as Step 2 in the illustration), since you shouldn't return http-01 authorizations in Step 1 for this case. For authorizations created in response to a request (i.e. the non-preauth flow, which this draft explicitly states is allowed in 5.1), the CA has to make a determination about what authorizations to issue, and the state to track all of those pending authorizations created, which gets us back to the discussion. The significant majority of CAs, for the majority of certificates issued by these CAs, totally rely upon authorizing "lex.example" in order to issue certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or other). So I'm not sure what you mean by "does not demonstrate control". Hopefully, this reply helps clarify, but if you still aren't sure, I'm hoping you could be clearer on the uncertainty and I'll do my best to rephrase. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
Ryan Sleevi wrote: >> The client has control over lex.example, but and can prove it with dns-01 >> TXT >> record placed at _acme-challenge.lex.example. Why does it matter whether >> it >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. >> or an.other.comp.lex.example?? > The mistake you’ve made here is assuming the client has control over > lex.example, and thus all subdomains. The point of all of this is that is > an unrealistic assumption: the client may only have control over the DNS > zone at so.me.comp.lex.example or they might have control at the > me.comp.lex.example, but no control at comp.lex.example. I don't understand. If the client doesn't control lex.example, then why would it expect to get any kind of control of that? Same as without subdomains. > The existing approach with ACME assumes and expects that validation will be > done at the FQDN (this is an oversimplification, but the nuance here isn’t > as important). Yes, the FULLY-QUALIFIED. Not the public name. dns-01 works just fine today for so.me.comp.lex.example. The client does not demonstrate control over lex.example using dns-01 when it asks for so.me.comp.lex.example. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
On Mon, Dec 7, 2020 at 8:30 AM Michael Richardson wrote: > > Ryan, I'm not really following this conversation. > Probably my mental model of dns-01 challenges is lacking. > The word "window" does not appear in RFC8555 or acme-subdomains, so that's > your word, I think. > > Ryan Sleevi wrote: > > 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 really understand this at all. > I think that we are discussing so.me.comp.lex.example. > > The client has control over lex.example, but and can prove it with dns-01 > TXT > record placed at _acme-challenge.lex.example. Why does it matter whether > it > is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. > or an.other.comp.lex.example?? The mistake you’ve made here is assuming the client has control over lex.example, and thus all subdomains. The point of all of this is that is an unrealistic assumption: the client may only have control over the DNS zone at so.me.comp.lex.example or they might have control at the me.comp.lex.example, but no control at comp.lex.example. The existing approach with ACME assumes and expects that validation will be done at the FQDN (this is an oversimplification, but the nuance here isn’t as important). The point is that if the server decides to challenge lex.example or comp.lex.example, it will fail for this client, so that’s why we need some form of either/or or both/and of multiple challenges and a client indicated set of capabilities. The window is simply which labels you select: the example you chose has five labels, so whether we select the “first” two domains (“so” and “me” working from most to least specific) or the “middle” two (“comp” and “lex”) matters. Similarly, it’s valid to issue a challenge for “example” in all of its glory: this comes up with ICANN Spec-9/Spec-13 gTLDs, and so it’s useful to allow the client to say “no, really, validate the *entire* namespace”. So even if the server challenged “lex.example” that could be the wrong level. One thing that just occured to me is whether or not there is any value in > the > dns-01 challenge remaining in the DNS after the authorization. > What I'm thinking is that the CA could offload some of it's state for the > client to store for it. I don’t think it’s reasonable at all to make changes like that. It would either limit issuance of multiple independent certificates within a time period (collision on _acme-validation) or would encourage the use of random values in the labels. > > > 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”. > > I can't see how any of these things are anything other than serious bugs. I didn’t say they weren’t. But just like C is a fundamentally insecure language that no one ethically responsible or security conscious should choose as a first choice for new code, the ergonomics of the decisions here are worth pointing out. There are Top 10 CAs that are misissuing certificates because they found it “confusing” to locate requirements [1] or manually implement the CAA lookup algorithm by hand for every request [2]. My intent in pointing these out is to acknowledge that we have to contemplate the worst possible implementations, and view the risks through that lens, when thinking about risks or tradeoff. We simply can’t assume a competent implementation, unfortunately. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1662807 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1651026#c12 > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
Ryan, I'm not really following this conversation. Probably my mental model of dns-01 challenges is lacking. The word "window" does not appear in RFC8555 or acme-subdomains, so that's your word, I think. Ryan Sleevi wrote: > 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 really understand this at all. I think that we are discussing so.me.comp.lex.example. The client has control over lex.example, but and can prove it with dns-01 TXT record placed at _acme-challenge.lex.example. Why does it matter whether it is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. or an.other.comp.lex.example?? One thing that just occured to me is whether or not there is any value in the dns-01 challenge remaining in the DNS after the authorization. What I'm thinking is that the CA could offload some of it's state for the client to store for it. > 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”. I can't see how any of these things are anything other than serious bugs. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
On Sun, Dec 6, 2020 at 9:32 PM Owen Friel (ofriel) 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
Re: [Acme] acme subdomains open items
From: Ryan Sleevi Sent: 05 December 2020 03:27 To: Owen Friel (ofriel) Cc: Felipe Gasper ; acme@ietf.org Subject: Re: [Acme] acme subdomains open items Thanks for bringing it to the list, Owen. This is something we're trying to lock down in the CA/B Forum, at least with respect to the 'http-01' method, by making it clear that, like tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a domain and all of its descendents), only as an FQDN. So this method primarily is for the 'dns-01' method, which seems to suggest that, at a minimum, the ACME server needs to indicate to the ACME client what modifications it will accept, since the ACME client will need to actually modify the DNS record at the appropriate label. If the server only chooses a single label, then it seems both likely and possible that the server may choose a dns-01 challenge that the client cannot fulfill (e.g. the client can only modify subdomain.example.com<http://subdomain.example.com> and descendents, but the server/CA chooses to challenge against example.com<http://example.com>) So I *think* it would benefit from having the server be able to issue challenges against several identifiers, and communicate that to the client, which seems to argue "Yes" for your question #2. [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. 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<http://subdomain.example.com>, it doesn't benefit the client at all if the server chooses to also allow example.com<http://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? Does that accurately capture things? [ofriel] Exactly the questions I am asking. On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel) mailto:40cisco@dmarc.ietf.org>> wrote: That is what is currently documented – the server simply picks the one domain that it wants the client to fulfil the challenge against. That was presented as the current documented approach. And I also presented the open questions if we needed to build flexibility in client request and/or server response. There were no concrete opinions as far as I recall (waiting on the exact minutes) and Rich said to bring the qs to the mailer for further discussion. Cheers, Owen From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of Felipe Gasper Sent: 04 December 2020 21:35 To: Owen Friel (ofriel) mailto:40cisco@dmarc.ietf.org>> Cc: acme@ietf.org<mailto:acme@ietf.org> Subject: Re: [Acme] acme subdomains open items I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to choose whether it tries authz against parent domains without the client’s requesting it? This is how our (non-ACME) Sectigo integration works currently, and it suits us well. -F On Dec 4, 2020, at 02:23, Owen Friel (ofriel) mailto:ofriel=40cisco@dmarc.ietf.org>> wrote: Hi all, As recommended by the chairs at IETF109, bring the two open items to the list for discussion. These were raised by Felipe and Ryan previously. 1: Does the client need a mechanism to indicate that they want to authorize a parent domain and not the explicit subdomain identifier? Or a mechanism to indicate that they are happy to authorize against a choice of identifiers? E.g. for foo1.foo2.bar.example.com<http://foo1.foo2.bar.example.com>, should the client be able to specify anywhere from 1 to 4 identifiers they are willing to fulfil challenges for? 2: Does the server need a mechanism to provide a choice of identifiers to the client and let the client chose which challenge to fulfil? E.g. for foo1.foo2
Re: [Acme] acme subdomains open items
Thanks for bringing it to the list, Owen. This is something we're trying to lock down in the CA/B Forum, at least with respect to the 'http-01' method, by making it clear that, like tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a domain and all of its descendents), only as an FQDN. So this method primarily is for the 'dns-01' method, which seems to suggest that, at a minimum, the ACME server needs to indicate to the ACME client what modifications it will accept, since the ACME client will need to actually modify the DNS record at the appropriate label. If the server only chooses a single label, then it seems both likely and possible that the server may choose a dns-01 challenge that the client cannot fulfill (e.g. the client can only modify subdomain.example.com and descendents, but the server/CA chooses to challenge against example.com) So I *think* it would benefit from having the server be able to issue challenges against several identifiers, and communicate that to the client, which seems to argue "Yes" for your question #2. 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. Does that accurately capture things? On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel) wrote: > That is what is currently documented – the server simply picks the one > domain that it wants the client to fulfil the challenge against. > > > > That was presented as the current documented approach. And I also > presented the open questions if we needed to build flexibility in client > request and/or server response. There were no concrete opinions as far as I > recall (waiting on the exact minutes) and Rich said to bring the qs to the > mailer for further discussion. > > > > Cheers, > > Owen > > > > > > *From:* Acme *On Behalf Of *Felipe Gasper > *Sent:* 04 December 2020 21:35 > *To:* Owen Friel (ofriel) > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] acme subdomains open items > > > > I wasn’t part of IETF 109 .. was it discussed simply to give CAs the > ability to choose whether it tries authz against parent domains without the > client’s requesting it? > > > > This is how our (non-ACME) Sectigo integration works currently, and it > suits us well. > > > > -F > > > > On Dec 4, 2020, at 02:23, Owen Friel (ofriel) < > ofriel=40cisco@dmarc.ietf.org> wrote: > > > > Hi all, > > > > As recommended by the chairs at IETF109, bring the two open items to the > list for discussion. These were raised by Felipe and Ryan previously. > > > > 1: Does the client need a mechanism to indicate that they want to > authorize a parent domain and not the explicit subdomain identifier? Or a > mechanism to indicate that they are happy to authorize against a choice of > identifiers? > > > > E.g. for foo1.foo2.bar.example.com, should the client be able to specify > anywhere from 1 to 4 identifiers they are willing to fulfil challenges for? > > > > 2: Does the server need a mechanism to provide a choice of identifiers to > the client and let the client chose which challenge to fulfil? > > > > E.g. for foo1.foo2.bar.example.com, should the server be able to specify > anywhere from 1 to 4 identifiers that the client can pick from to fulfil? > > > > Both 1 and 2 require JSON object definition changes. Currently, the > document only defines how a client can submit a newOrder / newAuthz for a > subdomain, and the server can chose any one parent identifier that it > requires a challenge fulfilment on > > > > Owen > > > > > https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01 > > > > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4 > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
That is what is currently documented – the server simply picks the one domain that it wants the client to fulfil the challenge against. That was presented as the current documented approach. And I also presented the open questions if we needed to build flexibility in client request and/or server response. There were no concrete opinions as far as I recall (waiting on the exact minutes) and Rich said to bring the qs to the mailer for further discussion. Cheers, Owen From: Acme On Behalf Of Felipe Gasper Sent: 04 December 2020 21:35 To: Owen Friel (ofriel) Cc: acme@ietf.org Subject: Re: [Acme] acme subdomains open items I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to choose whether it tries authz against parent domains without the client’s requesting it? This is how our (non-ACME) Sectigo integration works currently, and it suits us well. -F On Dec 4, 2020, at 02:23, Owen Friel (ofriel) mailto:ofriel=40cisco@dmarc.ietf.org>> wrote: Hi all, As recommended by the chairs at IETF109, bring the two open items to the list for discussion. These were raised by Felipe and Ryan previously. 1: Does the client need a mechanism to indicate that they want to authorize a parent domain and not the explicit subdomain identifier? Or a mechanism to indicate that they are happy to authorize against a choice of identifiers? E.g. for foo1.foo2.bar.example.com, should the client be able to specify anywhere from 1 to 4 identifiers they are willing to fulfil challenges for? 2: Does the server need a mechanism to provide a choice of identifiers to the client and let the client chose which challenge to fulfil? E.g. for foo1.foo2.bar.example.com, should the server be able to specify anywhere from 1 to 4 identifiers that the client can pick from to fulfil? Both 1 and 2 require JSON object definition changes. Currently, the document only defines how a client can submit a newOrder / newAuthz for a subdomain, and the server can chose any one parent identifier that it requires a challenge fulfilment on Owen https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01 https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4 ___ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to choose whether it tries authz against parent domains without the client’s requesting it? This is how our (non-ACME) Sectigo integration works currently, and it suits us well. -F > On Dec 4, 2020, at 02:23, Owen Friel (ofriel) > wrote: > > > Hi all, > > As recommended by the chairs at IETF109, bring the two open items to the list > for discussion. These were raised by Felipe and Ryan previously. > > 1: Does the client need a mechanism to indicate that they want to authorize a > parent domain and not the explicit subdomain identifier? Or a mechanism to > indicate that they are happy to authorize against a choice of identifiers? > > E.g. for foo1.foo2.bar.example.com, should the client be able to specify > anywhere from 1 to 4 identifiers they are willing to fulfil challenges for? > > 2: Does the server need a mechanism to provide a choice of identifiers to the > client and let the client chose which challenge to fulfil? > > E.g. for foo1.foo2.bar.example.com, should the server be able to specify > anywhere from 1 to 4 identifiers that the client can pick from to fulfil? > > Both 1 and 2 require JSON object definition changes. Currently, the document > only defines how a client can submit a newOrder / newAuthz for a subdomain, > and the server can chose any one parent identifier that it requires a > challenge fulfilment on > > Owen > > https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01 > > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4 > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] acme subdomains open items
Hi all, As recommended by the chairs at IETF109, bring the two open items to the list for discussion. These were raised by Felipe and Ryan previously. 1: Does the client need a mechanism to indicate that they want to authorize a parent domain and not the explicit subdomain identifier? Or a mechanism to indicate that they are happy to authorize against a choice of identifiers? E.g. for foo1.foo2.bar.example.com, should the client be able to specify anywhere from 1 to 4 identifiers they are willing to fulfil challenges for? 2: Does the server need a mechanism to provide a choice of identifiers to the client and let the client chose which challenge to fulfil? E.g. for foo1.foo2.bar.example.com, should the server be able to specify anywhere from 1 to 4 identifiers that the client can pick from to fulfil? Both 1 and 2 require JSON object definition changes. Currently, the document only defines how a client can submit a newOrder / newAuthz for a subdomain, and the server can chose any one parent identifier that it requires a challenge fulfilment on Owen https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01 https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
