Appendix A. Design Rationale

Appendix A. Design Rationale

The TLS ALPN challenge exists to iterate on the TLS SNI challenge defined in the early ACME drafts. The TLS SNI challenge was convenient for service providers who were either operating large TLS-layer load balancing systems at which they wanted to perform validation or running servers fronting large numbers of DNS names from a single host as it allowed validation purely within the TLS layer. The value provided by the TLS SNI challenge was considered large enough that this document was written in order to provide a new challenge type that addressed the existing security concerns.

A security issue in the TLS SNI challenge was discovered by Frans Rosen, which allowed users of various service providers to illegitimately validate control of the DNS names of other users of 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 had registered with a service provider (i.e., if a user registered a.example, they would only be able to respond to SNI requests for a.example and not for SNI requests for b.example). It turns out that a number of large service providers do not honor this property. Because of this, users were able to respond to SNI requests for the names used by the TLS SNI challenge validation process. This meant that (1) if User A and User B had registered Host A and Host B, respectively, User A would be able to claim the constructed SNI challenge name for Host B, and (2) when the validation connection was made, User A would be able to answer, thereby proving control of Host B. As the SNI name used was a subdomain of the domain name being validated, rather than the domain name itself, it was likely to not already be registered with the service provider for traffic routing, making it much easier for a hijack to occur.