Orie Steele has entered the following ballot position for draft-ietf-acme-onion-05: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-onion/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Orie Steele, ART AD, comments for draft-ietf-acme-onion-05 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-acme-onion-05.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### Double encoding ``` 270 csr (required, string) The CSR in the base64url-encoded version of 271 the DER format. (Note: Because this field uses base64url, and 272 does not include headers, it is different from PEM.) ``` Its a shame there is double encoding here, but I gather it is to support extensibility. I'm sure its been considered, but I will state it it anyway, the csr can be transported as the payload without json object encapsulation. For example: ``` 278 { 279 "protected": base64url({ 280 "alg": "ES256", 281 "kid": "https://example.com/acme/acct/evOfKhNU60wg";, 282 "nonce": "UQI1PoRi5OuXzxuX7V7wL0", 283 "url": "https://example.com/acme/chall/bbc625c5";, "cty": "application/pkcs10", 284 }), 285 "payload": base64url( <<bytes>> ), 288 "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" 289 } ``` I see that the extensibility to the payload is later used for "onionCAA" in an example, so feel free to ignore this comment, assuming that parameter is not natural to include in the CSR. ### indeterminate wait ``` 341 In the case the Ed25519 public key is novel to the client it will 342 have to resign and republish its hidden service descriptor. It 343 SHOULD wait some (indeterminate) amount of time for the new 344 descriptor to propagate the Tor hidden service directory servers, 345 before proceeding with responding to the challenge. This should take 346 no more than a few minutes. This specification does not set a fixed ``` It is sorta determined below... Also, if the should is ignored or the window is too short, the check will fail, so this is really a MUST wait for the service to be published to the network, and the timing is simply unknown? ### acmeforonions.org ``` 386 create2-formats 2 387 single-onion-service 388 caa 128 issue "test.acmeforonions.org;validationmethods=onion-csr-01" 389 caa 0 iodef "mailto:secur...@example.com"; 390 introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3 391 KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs= 392 ... ``` Very cool site! It is mentioned in the implementation report, but that will be removed on publication. Consider an alternative citation for "acmeforonions.org", and although this is a style nit, I prefer to use examples that are not functional, and will therefore age consistently, such as acmeforonions.example. Consider that "acmeforonions.org" may change ownership or content in the future. ### SHOULD wait? ``` 426 If the hidden service has client authentication enabled then it will 427 be impossible for the ACME server to decrypt the second layer 428 descriptor to read the CAA records until the ACME server's public key 429 has been added to the first layer descriptor. To this end an ACME 430 server SHOULD wait until the client responds to an authorization 431 before checking CAA, and treat this response as indication that their 432 public key has been added and that the ACME server will be able to 433 decrypt the second layer descriptor. ``` Is this really a MUST? given the "impossible" comment? ### Alternative channels for requesting certs ``` 755 ACME clients SHOULD connect to ACME servers over the Tor network to 756 alleviate this, preferring a hidden service endpoint if the CA 757 provides such a service. ``` The use of SHOULD here, implies there are alternatives which might be better choices, I wonder what those might be. ## Nits ### Framing ``` 652 suitability. The reasons the author wishes to pursue this path in 653 the first place are detailed in Appendix A. It is felt that there is ``` This is a proposed standard from a WG, hopefully the working group is supportive of this path as well : ) This comment also applies to Appendix A. ### MUST consider privacy ``` 709 A site operator SHOULD consider the privacy implications of 710 redirecting to a non-".onion" site - namely that the ACME server 711 operator will then be able to learn information about the site 712 redirected to that they would not if accessed via a ".onion" Special- 713 Use Domain Name, such as its IP address. If the site redirected to ``` I'm not sure why making it not a MUST is better guidance. There are a few other SHOULD consider's in Sec Considerations, which seem like MUSTs to me. Especially this section: ``` 759 If an ACME client requests a publicly trusted WebPKI certificate it 760 will expose the existence of the Hidden Service publicly due to its 761 inclusion in Certificate Transparency logs [RFC9162]. Hidden Service 762 operators SHOULD consider the privacy implications of this before 763 requesting WebPKI certificates. ACME client developers SHOULD warn 764 users about the risks of CT logged certificates for hidden services. ``` Especially risky for experimental / test / demographic specific sub environments, like high-value.target.....onion. The next section basically says this, so maybe its a no-op, but I'd prefer stronger warnings than SHOULD on this front. _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
