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

[Seo Suchan <[e-mail]>]

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