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

[Q Misell <[e-mail]>]

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