Paul Wouters has entered the following ballot position for draft-ietf-acme-subdomains-06: Discuss
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-subdomains/ ---------------------------------------------------------------------- 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. ### 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. ### Wildcards? It is unclear to me how DNS wildcards, eg "*.nohats.ca" should be handled? Do they fall within the permissions granted by "subdomainAuthAllowed"? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comment ### Section 4.1 ``` This field MUST be present and true [...] ``` This is a bit confusing. "(MUST be present) AND (TRUE)" is not meant. What is meant is "If present, MUST be true". ### NITS examples with date use old dates, eg: ``` "expires": "2015-03-01T14:09:07.99Z", "validated": "2014-12-01T12:05:58.16Z" ``` Maybe bump them a little to 2022/2023 ? _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
