Re: [Acme] Onion address validation extension

[Ryan Sleevi <[e-mail]>]

On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara <[e-mail]>
wrote:

> On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
> > Couldn’t it be done in the way that the ACME server creates a nonce.
>
> I am not sure why the client nonce is there. And I can not quickly find
> any discussion about cryptographic reasons.


This goes back to when it was originally introduced, and v2 addresses were
in use. It’s about mitigating the cross-protocol attack scenario.

The desire was to avoid having to introduce a full Tor implementation for a
CA to validate. It was seen that some POP was needed, not of the TLS Key,
but if the associated Tor HS key, in order to actually demonstrate some
association / “ownership” of the domain.

Having the whole CSR be signed meant the CSR would be replayable. So a CA
provided nonce was added, so the CA can demonstrably prove it was fresh.
However, if only CA data was used, then particularly with v2 addresses
(using SHA-1), there was a concern that a malicious CA might try to
compromise the HS security by making the CSR request a cross-protocol
signing oracle, supplying hostile nonces. So the client random was added,
to add entropy and otherwise mitigate this admittedly convoluted case. But
this was all predicated on v2 just having awful cryptographic properties
(truncated SHA-1 and 1024-bit RSA says what).

Unfortunately, you’re correct for pointing out that since the OID
allocations placed the CA attribute over the applicant attribute, the sort
of the SET of ATTRIBUTES defeats this. Alas, this is why the CABF benefits
from greater public participation.

The original thread starts around November-2014,
https://lists.cabforum.org/pipermail/public/2014-November/004569.html .
It’s easy to miss, because it around the same time there were discussions
of shortening certificate lifetimes and requiring id-kp-serverAuth in
certificates, things the CABF is **finally** getting around to doing in 2020

It could be for hash strenthening. However, that explanation is
> problematic:
>
> - The signature scheme is Ed25519, which has built-in hash
>   strengthening.
> - For hash strenthening via applicant nonce to actually work, the
>   CSR must have applicant nonce before CA nonce.
>
> However, I do not think it is impossible that it is indeed for hash
> strengthening and these two details were just missed.
>
> > 2 – OR the client can choose to submit the validation result inside
> > the final CSR. There is a object in the CSR called ”Challenge
> > password”, which could be ”reused” for this purpose, by filling it
> > with the result of the validation (ergo a signature by the onion
> > private key over the nonce).
>
> I do not think that would work for two reasons:
>
> - ACME protocol is not meant to proceed to CSR sending until after all
>   names are validated. Breaking that would cause implementation
>   problems.
> - The CSRs are assumed to be self-signed, which is a problem here:
>   - The signature needs to be from Tor key for obvious reasons.
>   - The Tor keys are Ed25519, which is not allowed in WebPKI,
>     even for subscriber certificates.
>   - Even if the keys were allowed, using them for TLS is not
>     cryptographically kosher. However, there should be no problems in
>     this case.
>
>
> For designing a cleaner mechanism to propose to CABForum, I think
> reasonable starting point would be to model it like the ACME key-
> change endpoint.  However, signing JOSE messages with Tor key is
> not cryptographically kosher (just like singing CSRs with it is
> not kosher). However, again there should be no problems in practice
> (Tor itself never signs with this key, only derives other keys from
> it).


I think the odds of a change in the Forum are low here. I’ll readily admit,
I am intentionally rather hostile to JOSE / COSE being introduced into the
CABF, because of the consistent and persistent security failures these
formats lead to.

That said, given the rather significant improvements to the cryptographic
constructions of v3, I’m also quite keen for any establishment protocol in
the CSR that can suitably demonstrate a POP within the CSR. It needs to be
robust to cross-protocol reuse, but I suspect that is now substantially
easier given the v3 construction. I suspect that would also make it easier
for ACME, but perhaps I’m overlooking why even a simplified form is
challenging?

>