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

[Michael Richardson <[e-mail]>]

Ryan Sleevi <[e-mail]> wrote:
    > Now, the system can already dispatched based on hostname, ensuring that
    > good.example sessions are served Customer A's response, and
    > evil.example sessions are served Customer B's response. The issue is
    > whose response is served when there is no SNI? Under a TLS-ALPN (no-ip)
    > model, there's no restrictions or requirements there; you could serve
    > Customer A, customer B, or neither - and none would undermine the
    > security of TLS-ALPN (as a validation method) or of the security
    > properties you're trying for.

okay, I'm with you so far.

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

    > In a world where we include the to-be-validated IP in the request, and
    > the Cloud Provider is observing the security invariants required for
    > TLS-ALPN (that any hostnames to be validated have been successfully
    > authenticated as belonging to the customer in question), then Customer
    > B would have to demonstrate control, to the provider, over
    > 2.0.0.10.in-addr.arpa in order to get such a certificate.

I see.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [