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

[Ryan Sleevi <[e-mail]>]

Good points!

I can't speak for the draft authors here, but my understanding and
expectation was, in part in response to the concerns with tls-sni mitigated
by tls-alpn, to ensure there's a strong binding from the request to the
response, and that the binding is unambiguous.

What I mean by that is that in the case of tls-sni, there wasn't a strong
binding between the host name of the challenge certificate and the host
name that the certificate would be issued for (the .invalid problem).
TLS-ALPN resolves this by introducing the ALPN identifier as the protocol
signal, and thus ensures a strong binding between the SNI name and the
final certificate - ensuring it's unambiguous as to what host name will be
challenged for.

As you note, TLS prohibits the use of the IP address in SNI, and thus makes
it difficult to have a strong binding between the name that the certificate
will be issued for and the challenge certificate. This leaves two options:
introduce an alternative way to encode the challenged-for IP in the request
(which the draft does) or omit it entirely (as I believe you're proposing).
If we go with the former approach, encoding it in the request, than servers
that are dispatching the request can ensure that it's only dispatched to
the entity responsible for the IP address encoded. If we go with the latter
approach, then servers would need to ensure that the SNI-less responses can
only be provided on the particular party authorized for that IP address.

The latter only becomes a consideration if multiple IPs are terminated at
the same TLS layer, and that TLS termination layer doesn't consider the
destination IP when dispatching certificates. If we were to omit the
binding, it'd likely be worthy of a security consideration to specify
guidance as to how to do so safely / considerations that should be done
before enabling TLS-ALPN in the context of IP. Alternatively, if we assume
they took the necessary steps for TLS-ALPN, then encoding the domain in the
SNI allows the existing dispatch protection mechanisms to work will
continue to work.

That's, at least, how I've viewed it :)

On Mon, Apr 22, 2019 at 9:21 PM Corey Bonnell <[e-mail]> wrote:

> 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]>
> 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?
>
>