Re: [Acme] Onion address validation extension

Ryan Sleevi <> Thu, 09 July 2020 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C155E3A0956 for <>; Thu, 9 Jul 2020 06:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h1msge8Speik for <>; Thu, 9 Jul 2020 06:01:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 391D83A0940 for <>; Thu, 9 Jul 2020 06:01:38 -0700 (PDT)
Received: by with SMTP id e18so951817pgn.7 for <>; Thu, 09 Jul 2020 06:01:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HWwJ7/QJa5W7YJNxALL9CLKd14pN4EPXjWNjuNG9u+I=; b=Fz3E0g8tqgtRtOyRKiQDMJ5n4s77XXQ7AcQelhK4ikUSw0P86dUOJHAuGr2HJhuqZF Me+7MTSy7CMl+o1B3qV7xRTa7JNUiXKS5iinF0z5p1+h4Tz4LFDwUECtNvxdksUv3YZF NPtBK9zhYIIe7iLDqHuWyrgCpwuWnTAC2FYlVxd0112J5w/EDdua+G7kTQlFDbRIvrbV YqCKP8piGt5705McYjJLDbf/KDAZ1wIxOyWbiwSEs4KXmorfCEqbkS9Mn7HuZdaUsXzw nO9xKihAjmlYCwkDISP+2+fs70ennZDPzRTZKgllnbbx8ez6xmwi1FG9LwOSE0OxCXpv WV/Q==
X-Gm-Message-State: AOAM532BBxDSNFcgy0pJP0x/KLZ7qzjlh/Eohw/0znRtRY1jXsTwxJUS uP+ycLvXhkGqOT/zKZZFlybVWGCZ
X-Google-Smtp-Source: ABdhPJx9MW1b2Wr+su9hFg5fOvWRU8ZM7401TLHOTZqG1bF/e9Q4bjPKCDEJH2F6kSX0QANQ0OU39Q==
X-Received: by 2002:aa7:8648:: with SMTP id a8mr58027773pfo.222.1594299697080; Thu, 09 Jul 2020 06:01:37 -0700 (PDT)
Received: from ( []) by with ESMTPSA id c30sm2645737pfj.213.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 06:01:37 -0700 (PDT)
Received: by with SMTP id f16so1084623pjt.0 for <>; Thu, 09 Jul 2020 06:01:36 -0700 (PDT)
X-Received: by 2002:a17:90a:21c6:: with SMTP id q64mr15746019pjc.172.1594299696385; Thu, 09 Jul 2020 06:01:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <002001d65552$1cd504d0$567f0e70$> <20200709123015.GA214719@LK-Perkele-VII>
In-Reply-To: <20200709123015.GA214719@LK-Perkele-VII>
From: Ryan Sleevi <>
Date: Thu, 09 Jul 2020 09:01:25 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Ilari Liusvaara <>
Cc: Mailing List <>, Sebastian Nielsen <>
Content-Type: multipart/alternative; boundary="0000000000001195e705aa01d387"
Archived-At: <>
Subject: Re: [Acme] Onion address validation extension
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jul 2020 13:01:42 -0000

On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara <>

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