Thanks Paul. The authors have been back and forth on these issues for the past month. See inline for summary.
-----Original Message----- From: Paul Wouters via Datatracker <nore...@ietf.org> Sent: Thursday, January 19, 2023 2:47 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-acme-subdoma...@ietf.org; acme-cha...@ietf.org; acme@ietf.org; debcool...@gmail.com; debcool...@gmail.com Subject: Paul Wouters' Discuss on draft-ietf-acme-subdomains-06: (with DISCUSS and COMMENT) ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Sec AD review of draft-ietf-acme-subdomains-06 CC @paulwouters 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. This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows automated tools to process items (eg to produce github issues) ## DISCUSS ### Zone bondary implications ``` the ACME client need only fulfill an ownership challenge against an ancestor domain identifier. ``` This document seems to have a "Public Suffix List" issue and no Security Considerations to cover this. PSL is mentioned in RFC 8555, but limited to the context of wildcards. The draft hints at the server being able to allow or not allow subdomain issuance but provides little guidance. I think at minimum, advise should be given not to allow issuance where it crosses a label that is present in the Public Suffix List (PSL). Additionally, it could say this should not be allowed for the root one or TLD zones, and that care should be taken with Empty Non Terminals (ENS), eg "co.uk". Currently, for a TLD to obtain a rogue certificate, it has to take over a child zone by issuing new NS records or issue a (DNSSEC signed) A or AAAA record directly into the child domain abusively crossing the zone cut. These are auditable or rejectable as these DNSSEC keys are not used fo subdomains in normal deployment. With this document, they just need to issue a TXT record into their own zone, which is indistinguishable from a normal operation of a DNSSEC zone key signing its own zone content. So I believe some security guidance here would be useful. [ofriel] Agreed. We will add some commentary similar to that in https://www.rfc-editor.org/rfc/rfc8555#section-10.5 ### Post compromise security This document allows an authorization object to be used in the future for additional sub/super domain ACME certificates. This does seem like a new security concern without a matching security consideration. While without this document, abuse could happen for an individual domain, this can now be extended to all domains under or one or more levels above it. An attacker could copy this object and use it at a much later date to issue fraudulent certificates for many subdomains. Related: Is there a way to indicate with ACME that this object should be de-authorized, to gain some post compromise security? I did not see anything listed in the security considerations of RFC8555. I did not see any recommendations for the expire: field in RFC 8555's Security Considerations Section. [ofriel] The authz object is the servers internal state that represents the specific client account authorization for a given identifier. Its not really the authz object that gets compromised, it’s the client account that gets compromised and allows the attacker to do whatever they want with that client account. We can clarify this in the security section and reference back to https://www.rfc-editor.org/rfc/rfc8555#section-7.3.6, which describes how a client can deactivate their account if account keys are compromised. ### Wildcards? It is unclear to me how DNS wildcards, eg "*.nohats.ca" should be handled? Do they fall within the permissions granted by "subdomainAuthAllowed"? [ofriel] We will add clarifying text that if server policy allows issuance of wildcard certs under a given ancestor domain, then it SHOULD include the "wildcard": true field in the authz object. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
