Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi <[e-mail]>]

On Tue, Apr 23, 2019 at 4:28 PM Michael Richardson <[e-mail]>
wrote:

>     > In a world where IPs were possible to be validated using TLS-ALPN,
> and
>     > the information omitted from the request, if evil.example/Customer B
>     > can serve a certificate that confirms the response for 10.0.0.2, then
>     > they could get a certificate for Customer A's IP.
>
> To do this requires that the cloud provider make a clear decision about
> what
> they are going to do with SNI-less requests above.    I feel that the cloud
> provider did something wrong here.


That's a not-unreasonable position to take, generally speaking, but it's
not an invariant that the TLS-ALPN method stated needed to be met. For
example, we 'could' just as well introduce yet-another-ALPN method to
indicate it's being used to validate an IP address, rather than a domain,
and then we can totally omit the IP address (encoded or otherwise) from the
TLS handshake, on the assumption that the Service Provider must be
responsible for determining the authorization scope. The use of a new ALPN
value would be explicit signalling by said Cloud Provider that they're
aware of the semantics and the security properties that need to be observed.

Fundamentally, TLS-SNI had problems because it relied on
implicit/out-of-band state to bind the request to the response (in this
case, the binding between the .acme.invalid namespace and the actual
customer namespace). As a result, the TLS terminator was not able to
dispatch or ACL appropriately. The 'main' contribution of TLS-ALPN was to
make the server explicitly signal support for the method, rather than
implicitly signal. We could have left the SNI domain as .acme.invalid and
still achieved the same security properties - however, moving it to use the
'actual' name, and only dispatch on ALPN, simply made it easier for Cloud
Providers to implement safely and securely.

That same logic applies here - we 'could' use a distinct ALPN method, in
which case, omitting the IP is fine. However, including the IP (albeit,
encoded) makes it easier to reason about, dispatch, and less likely to
result in implementation flaws, and in particular, given that the draft is
reusing the ALPN tag of TLS-ALPN, observes the semantics and security
properties required of servers that 'speak' TLS-ALPN.