Re: [Acme] Obtaining the Tor hidden service descriptor for draft-ietf-acme-onion

[Q Misell <[e-mail]>]

Hi all,

In-band CAA is now implemented on the reference CA at
https://acmeforonions.org and in the certbot-onion
<https://pypi.org/project/certbot-onion/> plugin.
draft-ietf-acme-onion-01 has also been published with the in-band CAA spec
(refined from my last email from issues that arose during implementation).

Cheers,
Q
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.


On Fri, 13 Oct 2023 at 17:19, Q Misell <[e-mail]> wrote:

> I've found some time to specify in-band CAA, a quick first draft is in the
> working draft[1]. Looking forward to hearing people's thoughts.
>
> [1]:
> https://as207960.github.io/acme-onion/draft-ietf-acme-onion.html#name-alternative-in-band-present
> ------------------------------
>
> Any statements contained in this email are personal to the author and are
> not necessarily the statements of the company unless specifically stated.
> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
> registered in Wales under № 12417574
> <https://find-and-update.company-information.service.gov.uk/company/12417574>,
> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
> <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867.
> EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
> 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
> maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
> Digital, is a company registered in Estonia under № 16755226. Estonian VAT
> №: EE102625532. Glauca Digital and the Glauca logo are registered
> trademarks in the UK, under № UK00003718474 and № UK00003718468,
> respectively.
>
>
> On Tue, 10 Oct 2023 at 21:22, Q Misell <[e-mail]> wrote:
>
>> Hi Silvio,
>>
>> Thanks for that info, that's quite helpful.
>>
>> I think the idea of allowing the client to just send the CAA lines signed
>> by its key would work well, and remove most if not all of the problems I've
>> been running into.
>> I'll work on implementing that in my draft, and see how difficult it'd be
>> to get that part only working in Boulder (as Let's Encrypt have already
>> indicated that they won't be implementing http-01 and tls-alpn-01 for
>> hidden services).
>>
>> Cheers,
>> Q
>> ------------------------------
>>
>> Any statements contained in this email are personal to the author and are
>> not necessarily the statements of the company unless specifically stated.
>> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
>> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
>> registered in Wales under № 12417574
>> <https://find-and-update.company-information.service.gov.uk/company/12417574>,
>> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
>> <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867.
>> EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
>> 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
>> maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
>> Digital, is a company registered in Estonia under № 16755226. Estonian VAT
>> №: EE102625532. Glauca Digital and the Glauca logo are registered
>> trademarks in the UK, under № UK00003718474 and № UK00003718468,
>> respectively.
>>
>>
>> On Tue, 10 Oct 2023 at 20:14, rhatto <[e-mail]> wrote:
>>
>>> On Thu, Sep 07, 2023 at 04:55:51PM +0100, Q Misell wrote:
>>> > I've had some discussion recently with the Tor project on
>>> implementation
>>> > hurdles for draft-ietf-acme-onion. One concern that has been raised by
>>> a few is
>>> > the need to run a Tor client to validate requests, even with
>>> onion-csr-01, due
>>> > to the inclusion of CAA in the draft.
>>>
>>> Hi Q, and thanks for bringing this up.
>>>
>>> > One solution proposed to this is that the ACME client MAY[1] send the
>>> hidden
>>> > service descriptor to CA as part of the finalize request. The CA also
>>> MAY
>>> > require this, if they do not wish to run a Tor client. This, to my
>>> knowledge,
>>> > wouldn't reduce the security of the validation of CAA, as the
>>> descriptor
>>> > document is still cryptographically validated in the same way using
>>> the current
>>> > network consensus. Additionally the directory authorities that serve
>>> > descriptors are already non-trusted actors in Tor.
>>> >
>>> > The CA would still need a copy of the network consensus document to
>>> verify
>>> > the descriptor submitted by the client. Most directory authorities
>>> however
>>> > are reachable over standard HTTP over TCP, in addition to HTTP over
>>> Tor.
>>> > This would allow the CA to fetch the current consensus without any
>>> > connection to Tor. The consensus fetched this way would still be
>>> verified
>>> > against the trusted directory authorities of Tor[2].
>>>
>>> Specifically, the "valid-after", "fresh-until", and "hsdir_interval" are
>>> the only consensus items needed to parse, decrypt and validate an Onion
>>> Service descriptor.
>>>
>>> > What are people's thoughts on this, and more importantly, what
>>> problems do
>>> > people see with this?
>>>
>>> After a lengthy discussion with Tor developers, we suggest the following
>>> options, prioritizing the least complex:
>>>
>>> 0. ACME clients MAY send "valid-after", "fresh-until" and "hs_interval"
>>>    along with the descriptor, which would allow the ACME Server to verify
>>>    CAA in a stateless way, without bootstrapping Tor to fetch the
>>>    descriptor and without fetching the network consensus.
>>>
>>> 1. Only the descriptor is sent by the ACME client, so the ACME server
>>> would
>>>    need to fetch and cache the network consensus.
>>>
>>> 2. The ACME client does not send the descriptor, leaving to the ACME
>>> server
>>>    the job of fetching it, as stated on draft-ietf-acme-onion-00.
>>>
>>> For options 0 and 1 above, there are two ways that a consensus (or just
>>> the
>>> needed items) can be fetched either by ACME clients or servers:
>>>
>>> a. Through the Tor network, from one of many directory caches.
>>>
>>>    As this involves bootstrapping Tor, it makes more sense for ACME
>>>    clients to do this fetching, as clients are probably already connected
>>>    to Tor in order to run an Onion Service or to make the ACME request
>>>    through Tor.
>>>
>>> b. Doing HTTP over TCP, or HTTP over Tor to the directory authorities.
>>>
>>>    While this is supported nowadays, it's not guaranteed to work in the
>>>    long term, since this method is deprecated in favor of the approach
>>>    above, and DirAuths may even stop serving the consensus directly by
>>> HTTP
>>>    at some point.
>>>
>>>    This also requires checking the DirAuths' signatures in the consensus
>>>    document.
>>>
>>> > Should this be incorporated into the draft?
>>>
>>> Yes, we support this idea, but also note that, despite parsing and
>>> validating an .onion descriptor being relatively straightforward, it
>>> involves more code to be maintained.
>>>
>>> We understand that signed CAA parameters could be accepted directly in
>>> an ACME API request without reducing security and the need to process an
>>> entire descriptor.
>>>
>>> --
>>> Silvio Rhatto
>>> pronouns he/him
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>