Re: [Acme] acme subdomains open items

[Ryan Sleevi <[e-mail]>]

On Mon, Dec 7, 2020 at 8:30 AM Michael Richardson <[e-mail]>
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 <[e-mail]> 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

>