On Tue, Apr 23, 2019 at 4:28 PM Michael Richardson <[email protected]> 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.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
