Subject: [Acme] Onion address validation extension

From: Roland Shoemaker <[email-masked]>
Date: Wed, 8 Jul 2020 10:46:49 -0700

With the recent passage of SC27 at the CA/Browser Forum there are now
acceptable mechanisms for validating v3 Onion addresses for inclusion in DV
certificates. As such it would be good to extend ACME to be able to make
use of these methods. I've written a short draft that covers what is likely
to be the most interesting validation mechanism to CAs (i.e. the one that
doesn't require actually using Tor directly) and would be interested in
thoughts from the WG.

The defined ACME challenge is basically just an adapted version of the
method defined in Appendix C 2.a of version 1.6.9 of the CABF BRs. I think
in general the usage of a CSR as the transport mechanism for the nonces and
key signature are a bit burdensome, and likely to cause some confusion for
implementers (since it introduces yet another place a CSR is
transferred between the client and server, with another non-standard use).
That said I think the first priority in this document is to get out
something that works with current CABF rules. There could be value though
in defining our own validation mechanism that is a bit more
straightforward alongside the existing CABF method and if/when this
document is standardized we could lobby for it's inclusion as a blessed
CABF validation method.

Thoughts?

https://www.ietf.org/id/draft-shoemaker-acme-onion-02.html

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Wed, 08 Jul 2020 20:03:40 +0200

Couldn’t it be done in the way that the ACME server creates a nonce.

Then there is 2 choices for the client to proceed:

1 – Either the client proceeds as in the draft, and submits the validation to the ACME server – this is required if the client wants to validate more than one domain name

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

This could be made as 2 different validation types: onion-01 and onion-02

Onion-01 requires responding to the validation (as usual as described in the draft), while onion-02 will always succeed at validation stage, but instead you submit the validation response in the final CSR.

(Note that the final CSR in onion-02 is then signed with the certificate private key, while it contains the nonce-signature of the onion-private-key inside the ”Challenge password” field).

Such a ”shortcut” validation method then skips the whole sequence of having to submit for validation, wait for it to succeed and wait for response etc. Its effectively short-cuts the whole process to the very final CSR – while still keeping the same security level.

Från: [email-masked] <[email-masked]> För Roland Shoemaker
Skickat: den 8 juli 2020 19:48
Till: IETF ACME <[email-masked]>
Ämne: [Acme] Onion address validation extension

With the recent passage of SC27 at the CA/Browser Forum there are now acceptable mechanisms for validating v3 Onion addresses for inclusion in DV certificates. As such it would be good to extend ACME to be able to make use of these methods. I've written a short draft that covers what is likely to be the most interesting validation mechanism to CAs (i.e. the one that doesn't require actually using Tor directly) and would be interested in thoughts from the WG.

The defined ACME challenge is basically just an adapted version of the method defined in Appendix C 2.a of version 1.6.9 of the CABF BRs. I think in general the usage of a CSR as the transport mechanism for the nonces and key signature are a bit burdensome, and likely to cause some confusion for implementers (since it introduces yet another place a CSR is transferred between the client and server, with another non-standard use). That said I think the first priority in this document is to get out something that works with current CABF rules. There could be value though in defining our own validation mechanism that is a bit more straightforward alongside the existing CABF method and if/when this document is standardized we could lobby for it's inclusion as a blessed CABF validation method.

Thoughts?

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 8 Jul 2020 23:57:19 +0300

> https://www.ietf.org/id/draft-shoemaker-acme-onion-02.html

Some comments from very quick reading:

- What is the OID prefix for CABF? I do not find it anywhere in the
  document, nor anywhere in the BR(!). Based on some searching, I guess
  it is 2.23.140 (thus cabf-caSigningNonce would be 2.23.140.41, and
  cabf-applicantSigningNonce would be 2.23.140.42).

- One should definitely have example of validation CSR. There are plenty
  of developers that do not have access to ASN.1 compilers (for many
  different reasons), but instead reverse-engineer real-world and test
  samples of various stuff when writing either ASN.1 parsing or
  serialization code. The alternative is them trying to read the ASN.1
  syntax (and likely getting it wrong, as CSR attributes are not
  trivial). No, they will not use ASN.1 compilers.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 9 Jul 2020 15:30:15 +0300

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

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

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 9 Jul 2020 09:01:25 -0400

> 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

> (Tor itself never signs with this key, only derives other keys from

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?

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Thu, 09 Jul 2020 17:51:33 +0200

>>ACME protocol is not meant to proceed to CSR sending until after all

Thats why there should be 2 validation types, so a client who support the new "skip ahead" validation type would know that it only needs to request onion-2 validation type, then it would immidiately skip ahead to CSR sending without checking if validation passed - since validation then occurs at CSR stage.

The reason validation is required inside ACME is because ACME (usually) needs to contact external resources to confirm your validations, which incurs a delay. If you can prove the ownership of the domain inside the actual validation response (ergo a self-validating response that can be verified "offline") theres no need to use the full blown ACME infrastructure, then you could just submit the response inside the final CSR.

Of course this wouldn't work for multiple domains, why the normal procedure with checking for validationa (onion-1) would be required.

>>The CSRs are assumed to be self-signed, which is a problem here:

Thats not a problem.
What I proposed, is that you create a CSR over the normal TLS certificate (with its signature belongning the TLS certificate's key) BUT you put your onion signature (a signature of the nonce made with the onion private key) inside the CSR field called "CSR Challenge Password".
 
So basically, you create a TOR signature with the TOR key, insert it in your final TLS CSR (as CSR Challenge Password), and then sign the TLS CSR with the TLS key.

Meaning, that the CSR *are* self-signed, and that they CONTAIN the TOR signature made with the TOR private key, making the CSR being dual-use - both validating the onion name AND also becomes the grounds for your certificate generation.

---

From: Roland Shoemaker <[email-masked]>
Date: Thu, 9 Jul 2020 09:51:18 -0700

I would be extremely uncomfortable specifying a mechanism like this. It
would be a large divergence from the existing ACME specification, and would
create significant traps for implementers to fall into. Specifically this
would break assumptions in most existing implementations, principally that
an order with valid authorizations can cause an issuance without further
validation. I'm also not sure how this would gel with implementations that
implement authorization reuse. It feels like this would create numerous
opportunities for an implementer to accidentally allow issuance without
actually doing any validation at all, for seemingly little real world
benefit (presumably this would only really save one or two additional
request roundtrips).

I think this is an example of one of the problems with the existing CABF
method of using a CSR as the data/signature transport when something else
would be more appropriate. The validation mechanism and the issuance
request mechanism should be as decoupled as possible to avoid people trying
to stick bits of either in the wrong place.

On Thu, Jul 9, 2020 at 8:51 AM Sebastian Nielsen <sebastian=
[email-masked]> wrote:

> Thats why there should be 2 validation types, so a client who support the
> new "skip ahead" validation type would know that it only needs to request
> onion-2 validation type, then it would immidiately skip ahead to CSR
> sending without checking if validation passed - since validation then
> occurs at CSR stage.
>
> The reason validation is required inside ACME is because ACME (usually)
> needs to contact external resources to confirm your validations, which
> incurs a delay. If you can prove the ownership of the domain inside the
> actual validation response (ergo a self-validating response that can be
> verified "offline") theres no need to use the full blown ACME
> infrastructure, then you could just submit the response inside the final
> CSR.
>
> Of course this wouldn't work for multiple domains, why the normal
> procedure with checking for validationa (onion-1) would be required.
>
> What I proposed, is that you create a CSR over the normal TLS certificate
> (with its signature belongning the TLS certificate's key) BUT you put your
> onion signature (a signature of the nonce made with the onion private key)
> inside the CSR field called "CSR Challenge Password".
>
> So basically, you create a TOR signature with the TOR key, insert it in
> your final TLS CSR (as CSR Challenge Password), and then sign the TLS CSR
> with the TLS key.
>
> Meaning, that the CSR *are* self-signed, and that they CONTAIN the TOR
> signature made with the TOR private key, making the CSR being dual-use -
> both validating the onion name AND also becomes the grounds for your
> certificate generation.
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Roland Shoemaker <[email-masked]>
Date: Thu, 9 Jul 2020 10:05:18 -0700

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

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2020 13:45:01 +0300

> for ACME, but perhaps I’m overlooking why even a simplified form is

It turns out that signing messages with Tor key does not have harmful
cryptographic interactions with the way Tor uses that key (due to EdDSA
also hashing the key when signing). 

The main issue with the present CSR method is complexity. The applicant
nonce does nothing useful (as due to ordering of the main EdDSA hash,
R already strenghens it). The description of format is too hard to
understand (an example would go long way to resolving the latter issue).

There are simpler constrctions that would do the POP. For example
(TLS syntax):

struct {
	opaque public_key[32];
	opaque nonce<22..255>;
} PopInner;

Sign PopInner structure using TLS 1.3 signature format with context
string "ACME, tor-rendv3-pop". Base64url-encode the 64-byte signature
and send it in ready for challenge request. 

CA can verify this by reconstructing the PoPInner from the known key
nonce and verifying the given signature with the key.

However, this does not do approval of ACME key (neither does the present
CSR method). I think the reason of approving old key with new key in
performing the key rollover is to prevent replaying new keys. Replay
here is prevented by the CA nonce.

And I think I found an issue in draft-shoemaker-acme-onion: It requires
only 64 bits of entropy for CA nonce, while BRs require 112, and base
ACME spec requires 128. Fix would be to change the first "64 bits of
entropy" in section 4 to "128 bits of entropy". This is presumably due
to confusing the two nonces, as applicant nonce can indeed be 64-bit.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Jul 2020 13:17:19 +0000

We have time on the agenda, so I am going to add some open discussion time for this.

On 7/21/20, 6:45 AM, "Ilari Liusvaara" <[email-masked]> wrote:

    struct {
    	opaque public_key[32];
    	opaque nonce<22..255>;
    } PopInner;

    -Ilari

    _______________________________________________
    Acme mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwIGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kBAk8JLDrgKC0IPKbyr4bCQAQ8pEZPcETi7Q0vjkUzA&s=xCkQ_STqxFwHRKntBP8xAnybPBYEL0JHJbkstYIyFIE&e=

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 10:46:57 -0400

> also hashing the key when signing).

That's an interesting point.
It seems that should there be future algorithms after EdDSA, that they could
adopt the same process.  But is there no interest in RSA? :-0

    > understand (an example would go long way to resolving the latter issue).

Is this just a documentation issue, or does it potentially introduce coding errors?

    > nonce and verifying the given signature with the key.

Interesting.

    > here is prevented by the CA nonce.

Can you explain what you mean by "replaying new keys".

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [