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

[Q Misell <[e-mail]>]

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