Re: [Acme] Onion address validation extension

[Roland Shoemaker <[e-mail]>]

On Thu, Jul 9, 2020 at 6:01 AM Ryan Sleevi <[e-mail]> wrote:

>
>
> 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.
>

I think we could probably do this without either the issues with JOSE JWS
or a CSR, for key rollover we require the new key to be sent along with the
signature over the old key so we utilized JWS headers for transmitting both
the signature and the new JWK. Since the onion address encodes the key
directly we already have what we need to validate a signature and all we
really need is the signature itself. A very simple solution would be to
have the client sign some strictly defined ASN.1 object (including say, the
name being validated, and some random value provided by the server) and
send that signature as the challenge response. This would create a higher
bar than using a CSR, since you wouldn't just be able to use some off the
shelf library like OpenSSL to create the challenge response, but since it's
unlikely that existing clients would be able to perform this validation
without extension anyway I don't think it's that significant of a hurdle to
add.


>
> 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?
>
>> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>