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

[Ryan Sleevi <[e-mail]>]

On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell <[e-mail]> wrote:

> Hello,
>
> Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an
> SNI value with the in-addr/ipv6.arpa domain name corresponding to the
> iPAddress being validated MUST be specified. I have a concern that this
> requirement suffers the same problem that rendered tls-sni-01 insecure:
> namely, an arbitrary user on a shared hosting provider could upload an
> arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus
> circumventing any security provided by the mandatory SNI extension.
>
> The mandatory ALPN extension prevents this from being exploited to obtain
> fraudulent certificates, but given how trivially the SNI requirement can be
> defeated in the same manner as for tls-sni-01, I don’t believe that
> requiring SNI provides any security value and is not necessary. If the
> intent for requiring the SNI extension is to convey to the TLS server that
> an IP address is being validated, couldn’t that similarly be accomplished
> by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames)
> requires that a SNI value be specified, so TLS servers could differentiate
> between challenge requests for dNSNames and iPAddress based on the presence
> (or absence) of the SNI extension.
>

I’m not sure I follow the attack scenario you’re describing. The value
proposition of the ALPN method is that it’s indicative that the server does
not “suffer the same problem that rendered sni-01 insecure”, precisely
because it does not allow an arbitrary user to upload an arbitrary
certificate while also responding with that ALPN identifier.

Perhaps I misunderstood your question, but with the above invariant being
the reason for the introduction of the ALPN method, if we assume it holds,
do you still have concerns?

>