From: Ryan Sleevi <ryan-i...@sleevi.com>
Sent: 05 December 2020 03:27
To: Owen Friel (ofriel) <ofr...@cisco.com>
Cc: Felipe Gasper <fel...@felipegasper.com>; 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) 
<ofriel=40cisco....@dmarc.ietf.org<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 <acme-boun...@ietf.org<mailto:acme-boun...@ietf.org>> On Behalf Of 
Felipe Gasper
Sent: 04 December 2020 21:35
To: Owen Friel (ofriel) 
<ofriel=40cisco....@dmarc.ietf.org<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) 
<ofriel=40cisco....@dmarc.ietf.org<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.bar.example.com<http://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<mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to