Thank you for your review. I think most of your suggestions are good, but have a few comments.
> Use short-lived certificates This doesn't make sense to me. A short lived cert will be permanently logged in CT. In fact using shorter certs means more entries for the onion service in the CT log - making it easier, not harder, to find. > Use a separate domain/key pair This goes counter to the whole idea of a PKI. Using a cert for a.onion on b.onion asserts very little useful. > CT Exemption Advocacy I don't think an RFC is the place to advocate for changes in a different organization, but otherwise agreed. I will incorporate the rest of your comments as appropriate. ------------------------------ 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, 29 Nov 2024 at 19:22, Derrell Piper via Datatracker < [email protected]> wrote: > Reviewer: Derrell Piper > Review result: Has Nits > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > The summary of the review is Ready With Nits > > My concern remains with the privacy risks of CT logs with onion > services. CT aims to improve TLS security but creates tensions with the > anonymity expected from onion services. So let me suggest some possible > mitigation text for the Security Considerations section without fully > understanding ACME or Tor. > > Use short-lived certificates: Request certificates with a short validity > period, such as 90 days or less. This reduces the window of exposure in > CT logs. You'll need to renew certificates more frequently, but it > limits the privacy impact. > > Avoid unnecessary certificate requests: Only request publicly-trusted > certificates for onion services that truly need them, such as those > serving websites to the general public (e.g. SecureDrop or news > outlets). For internal or non-public services, consider using > self-signed or privately-trusted certificates that don't get logged to > public CT. > > Use a separate domain/key pair: Register a distinct .onion address for > the specific purpose of obtaining a certificate, instead of using your > primary service's domain. This separates the publicly logged certificate > from your main onion service. > > Obfuscate subscriber information: When requesting certificates, provide > minimal or obfuscated subscriber details to the CA if possible, such as > a pseudonymous email address or entity name. The CA/Browser Forum > Baseline Requirements allow some flexibility here. But obfuscating > subscriber info with pseudonyms only reduces casual exposure but doesn't > guarantee anonymity, as CAs likely keep records mapping pseudonyms to > real identities. > > Monitor CT logs: Proactively monitor CT logs for certificates issued for > your onion domain(s). This can help detect any mis-issuance or > unauthorized certificates. Some CAs and third-party services offer CT > monitoring. > > Use ACME account key privacy: When using ACME, generate a new account > key pair for each .onion domain and avoid re-using keys across > domains. This reduces the ability to correlate multiple domains to a > single owner based on account keys. > > Private certificate authorities: For clusters of related onion services, > consider setting up a private CA that isn't constrained by the CT > logging requirement of public trust. This avoids any exposure in public > CT logs. Obvoiusly this is only viaable for larger onion service > deployments given the additional technical overhead. They aren't > feasible for all clusters of related services. > > Inform .onion Operators of CT Risks: ACME clients targeting .onion > domains should include explicit warnings about CT logging implications > to ensure operators make informed decisions. > > CT Exemption Advocacy: Advocate for discussions within the CA/Browser > Forum on potential CT exemptions for .onion services, given their unique > anonymity requirements. This could be accompanied by alternative > transparency mechanisms tailored to .onion ecosystems. > > Exploration of Private CT Logs: Research and development into private CT > logs or trusted third-party logging mechanisms for .onion services may > offer a compromise between transparency and privacy. > > > > > >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
