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

[Seo Suchan <[e-mail]>]

now I read it once again, I find in-band caa make less sense and just 
onion-csr challenge bypass CAA records:

as current status CAA nor CAA-critical posted won't ensure there will be 
no certificate because you can bypass with in-band projection from CA 
without Tor client, and they won't read reason to CAA-critical on first 
level descripter too, and with onion private key to sign csr with nonce 
it's possible to just post new descripter without CAA to tor network, as 
its what controls everything for that onion domain. and for 
http/tls-acme challenges CAA-critical is redundant, as such challenges 
will fail autometically if they can't access introduction points because 
can't decrypt second level. so my suggestion would be onion-csr 
challenges just ignore CAA, as with that key it's trival to just change 
it anyway, or enforce online CAA check.

2023-10-17 오후 6:53에 Q Misell 이(가) 쓴 글:
> > Well if CA is willing to run tor In house they can read caa record 
> tor network (CA/B br forbids using external proxy to access tor 
> website for verification purpose) and for onion challenge it already 
> have the key to sign this on demand.
> Good point, I evidently had not thought through things properly.
>
> > And it's kinda vague when acme server are running tor client and see 
> caa in finalization object : it may process it or ignore it and even 
> reject finalization because not implementing this extension as they 
> think not needed
>
> Yeah that bit does need further clarification. My intent was a CA may 
> process it if they want to, but are not required to do anything with 
> it, giving the following outcomes:
> - CA with a Tor client and no CAA in finalize: fetch CAA over Tor
> - CA without a Tor client and no COO in finalize: error
> - CA with a Tor client and CAA in finalize: either fetch CAA over Tor 
> or use provided CAA, up to CA preference, but do not error purely 
> because the CAA is there
> - CA without a Tor client and CAA in finalize: use provided CAA
>
> I'll work on making that clearer in the next revision.
> ------------------------------------------------------------------------
>
> 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, 17 Oct 2023 at 10:33, Seo Suchan <[e-mail]> wrote:
>
>     well if CA is willing to run tor In house they can read caa record
>     tor network (CA/B br forbids using external proxy to access tor
>     website for verification perpose) and for onion challenge it
>     already have the key to sign this on demand
>     and it's kinda vague when acme server are running tor client and
>     see caa in finalization object : it may process it or ignore it
>     and even reject finalization because not implementing this
>     extension as they think not needed
>
>
>     On 2023년 10월 17일 오후 6시 23분 21초 GMT+09:00, Q Misell
>     <[e-mail]> 작성함:
>
>         The rationale for expiry is that in the case of http-01 or
>         tls-alpn-01 the ACME client need not have access to the Onion
>         service's secret key. A long lived CAA signature could be
>         generated with the key, provided to the ACME client to use,
>         and the key could be kept away from the ACME client and only
>         available on the machine running the Tor proxy.
>         ------------------------------------------------------------------------
>
>         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, 17 Oct 2023 at 04:15, Seo Suchan <[e-mail]>
>         wrote:
>
>
>             not sure giving expiry by client side is meaningful: as we
>             send this at finalization step, and as something would be
>             very wrong if one request another certificate in 8 hours
>             from last certificate so whatever value client may put
>             there will be expired by the time we request: in effect
>             it'd be act more like timestamp and if it is I kinda want
>             it to be nonce for that certificate finalization explicitly.
>
>             2023-10-17 오전 3:10에 Q Misell 이(가) 쓴 글:
>>             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
>>
>>
>>             _______________________________________________
>>             Acme mailing list
>>             [e-mail]
>>             https://www.ietf.org/mailman/listinfo/acme
>             _______________________________________________
>             Acme mailing list
>             [e-mail]
>             https://www.ietf.org/mailman/listinfo/acme
>