Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
draft-ietf-acme-tls-alpn-07

Thanks for all the work that has gone into creating a viable
TLS-based mechanism for ACME validation. I have one fairly
important (yet trivial to fix) comment, and a small number
of editorial suggestions.

I also have read through the ARTART review, and endorse Martin's
comments. Please respond to that review, and incorporate his
suggestions as you feel appropriate.

---------------------------------------------------------------------------

§1:

>  The Automatic Certificate Management Environment (ACME) [RFC8555]
>  standard specifies methods for validating control of domain names via
>  HTTP and DNS.

As a fairly major comment, RFC 8555 is not a standard. See RFCs 2026 and
6410 for details.  Please rephrase this text along the lines of:

   The Automatic Certificate Management Environment (ACME) [RFC8555]
   specification describes methods for validating control of domain names
   via HTTP and DNS.

---------------------------------------------------------------------------

§3:

>  The TLS with Application Layer Protocol Negotiation (TLS ALPN)
>  validation method proves control over a domain name by requiring the
>  client to configure a TLS server to respond to specific connection
>  attempts utilizing the ALPN extension with identifying information.

This took a couple of readings before I understood what it meant.
It might make things clearer if the role of the client were clearer;
e.g., "...by requiring the ACME client to configure a TLS server..."

This is also true throughout much of this section, where "client"
and "server" are used without qualification to talk about ACME
clients and ACME servers. Consider qualifying such instances.

---------------------------------------------------------------------------

§3:

>  The client prepares for validation by constructing a self-signed
>  certificate which MUST contain a acmeIdentifier extension

Nit: "...contain an acmeIdentifier..."

---------------------------------------------------------------------------

§3:

>  3.  The AMCE server initiates a TLS connection to the chosen IP
>      address, this connection MUST use TCP port 443.  The ACME server
>      MUST provide a ALPN extension with the single protocol name
>      "acme-tls/1" and a SNI extension containing only the domain name
>      being validated during the TLS handshake.

Nit: "...chosen IP address. This connection..."

Nit: "...an ALPN..."

Nit: "...an SNI..."

---------------------------------------------------------------------------

§5:

Unlike section 3, this section appears to use unqualified "server"
to mean "HTTPS server" or somesuch, rather than "ACME server".
These *definitely* need to be qualified.

Please respond to the ARTART review; there's some good comments in there
about constraining the permitted TLS versions/algorithms, the specifics
of the acme-tls/1 (non-)protocol, the use of a different certificate
model than RFC 5280, and the (non-)need to complete the TLS handshake.

Section 1

"Because no existing software implements this protocol" is not going to
age well; perhaps an approach more like "Because this protocol does not
build on a preexisting deployment base" would do better.

Section 7

   the provider.  When the TLS SNI challenge was designed it was assumed
   that a user would only be able to respond to TLS traffic via SNI for
   domain names they controlled (i.e. if User A registered Host A and
   User B registered Host B with a service provider that User A wouldn't
   be able to respond to SNI traffic for Host B).  This turns out not to
   be a security property provided by a number of large service
   providers.  [...]

Perhaps I'm misremembering, but I don't think this characterizes exactly
the situation that led to the TLS SNI challenge being deemed
irredeemable: the issues arise when User B *has not yet* registered Host
B, and either the registration validation at the provider was lax or
User A could connive to get into the default-SNI handler.  The *attack*
was possible even when User B has registered Host B, because the
validation used a subdomain, as we discuss below, but here we are
talking about the SNI routing, which needed to be for an unregistered
(or not-validly-registered) name.