Re: [Acme] Paul Wouters' Discuss on draft-ietf-acme-subdomains-06: (with DISCUSS and COMMENT)

["Owen Friel (ofriel)" <[e-mail]>]

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 <[e-mail]> 
Sent: Thursday, January 19, 2023 2:47 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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.