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

[Ballot comment]
Thank you for this well-written and easy to read document. I have only one COMMENT:

Would it be useful to specify the use of "IPv4 or IPv6 address" rather than simply the implicit "address" that I read as  indeed IPv4/IPv6 but being explicit will not hurt.

-éric

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
I have only editorial comments below.  No response is needed — please just consider incorporating these, as I think they’ll help make the document clearer.

— Abstract —

  This document specifies a new challenge for the Automated Certificate
  Management Environment (ACME) protocol which allows for domain
  control validation using TLS.

This needs “that” insted of “which”, making the clause restrictive.

— Section 3 —

      Trailing'=' padding
      characters MUST be stripped.

There’s a space missing after “trailing”.

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

“That”, not “which”.

      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

Change “a” to “an” in both places (unless you realy say “snee” instead of “ess en eye”).

— Section 5 —

  The first assumption is that when a server is being used to serve
  content for multiple DNS names from a single IP address that it
  properly segregates control of those names to the users that own

The second “that” needs to go; the first one covers it.

  a TLS request using a
  SNI value for Host A

Again, “an”, unless…

— Section 7 —

  The TLS ALPN challenge exists to replace the TLS SNI challenge
  defined in the early ACME drafts.  This challenge was convenient for
  service providers who were either operating large TLS layer load

What is the antecedent to “this”?  Is it th ALPN challenge, or the SNI challenge?  I have no idea; please clarify.

  A security issue was discovered in the TLS SNI challenge by Frans
  Rosen which allowed users of various service providers to

The phrasing would be better this way, to avoid separation of the connected parts (the TLS SNI challenge was not by Frans Rosen):

NEW
  A security issue in the TLS SNI challenge was discovered by Frans
  Rosen, which allowed users of various service providers to
END

  (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).

First, “i.e.” needs a comma after it.  Second, I can’t parse this at all.  Can you please rephrase it so it makes sense?

  This turns out not to
  be a security property provided by a number of large service
  providers.

NEW
  It turns out that a number of large service providers do not
  honor this property.
END

  Because of this users were able to respond to SNI traffic

I’ve ignored a lot of missing commas, but this one really needs one after “this”.

  This meant that if User A and User B had registered Host A and Host B
  respectively User A would be able to claim the SNI name for Host B
  and when the validation connection was made that User A would be able
  to answer, proving 'control' of Host B.

Comma needed both before and after “respectively”, and another after “made”.

— Section 8 —

  and especially Frans
  Rosen who discovered the vulnerability in the TLS SNI method which
  necessitated the writing of this specification.

Add a comma after “Rosen”, and change “which” to “that”.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-acme-tls-alpn-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the SMI Security for PKIX Certificate Extension registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

the existing registration for

Decimal: 31
Description: id-pe-acmeIdentifier
References: [draft-ietf-acme-tls-alpn]

will have its reference changed to [ RFC-to-be ].

Second, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a new registration is to be made as follows:

Protocol: ACME-TLS/1
Identification Sequence: 0x61 0x63 0x6d 0x65 0x2d 0x74 0x6c 0x73 0x2f 0x31 ("acme-tls/1")
Reference: [ RFC-to-be ]

As this section requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry have asked that you send a review request to the mailing list specified in RFC 8447. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the ACME Validation Methods registry on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a new registration is to be made as follows:

Label: tls-alpn-01
Identifier Type: dns
ACME:
Reference: [ RFC-to-be ]

IANA Question --> Should the entry for "ACME" for this registration be "Y" or "N?"

As this also requests registration in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-09-25):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, Daniel McCarney , draft-ietf-acme-tls-alpn@ietf.org, acme@ietf.org, cpu@letsencrypt.org, acme-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ACME TLS ALPN Challenge Extension) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'ACME TLS ALPN
Challenge Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies a new challenge for the Automated Certificate
  Management Environment (ACME) protocol which allows for domain
  control validation using TLS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/ballot/


No IPR declarations have been submitted directly on this I-D.

# Technical Summary

The ACME-TLS-ALPN draft extends the Automatic Certificate Management Environment
(ACME) with a new domain validation challenge type (tls-alpn-01) that can be
performed at the TLS layer alone. This challenge type meets the need of users
(hosting providers, CDNs, etc) who wish to prove authorization of a DNS
identifier withoout modifying HTTP handling behaviour or updating DNS zone data.
This is the spiritual successor to the deprecated/removed TLS-SNI-01/02
challenge types from earlier ACME drafts.

# Working Group Summary

Earlier drafts specified a id-pe-acmeIdentifier OID that was already assigned by
IANA. This has been addressed in the latest draft. The ASN.1 format of the
id-pe-acmeIdentifier was also both simplified (removing an unneeded subarc from
the OID) and clarified (to emphasize the SHA-256 digest value).

# Document Quality

Let's Encrypt, a high-volume ACME based CA, has fully implemented the
tls-alpn-01 challenge type and has been issuing certificates in production using
this challenge type since July 12th, 2018. Multiple independent ACME clients
have implemented support for this challenge type.

The overall document quality is high. Developing an implementation based on the
specification text is reasonable. Interoperable client/server implementations
exist and are in use in a production setting.

# Personnel

The document shepard is Daniel McCarney. The responsible area director is Eric
Rescorla.

# IRTF Note

Not applicable

# IESG Note

Not applicable

# IANA Note

There are three IANA considerations in Section 5. The "SMI Security for PKIX
Certificate Extension (1.3.6.1.5.5.7.1)" table requires an update. The
"Application-Layer Protocol Negotiation (ALPN) Protocol IDs" table needs an
update. The "ACME Validation Methods" table requires an update.