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

[Corey Bonnell <[e-mail]>]

Hi Ryan,
I suppose I should have framed my email a bit more generally as opposed to focusing specifically on the security aspects. More broadly, I'm having a hard time coming up with a reason why the SNI extension must be included at all for IP address challenges. In the normal TLS connection flow, a connection by direct IP address (not hostname) would not include the SNI extension at all, so mandating the use of the .arpa domain in the SNI is inconsistent with normal TLS processing. This inconsistency is compounded when you consider that the self-signed cert for the challenge encodes the IP address as an iPAddress SAN (and not the .arpa dNSName). I could also see someone being confused upon reading the spec and thinking that a DNS A/AAAA record lookup against the in-addr/ipv6.arpa domain must be performed and that the challenge TLS connection is to be done against the resolved IP address.

I believe it would be more consistent with normal TLS processing and less confusing to prohibit the use of SNI altogether for IP address validations. However, I'd greatly appreciate any explanations as to why it is preferable to include the SNI extension.

Thanks,
Corey

________________________________
From: Ryan Sleevi <[e-mail]>
Sent: Wednesday, April 17, 2019 1:05 AM
To: Corey Bonnell
Cc: [e-mail]
Subject: Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05



On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell <[e-mail]<mailto:[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?