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 <rha...@torproject.org> 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
