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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
