Re: [Acme] tls-alpn-01 spec: TLS-SNI history

[Ryan Sleevi <[e-mail]>]

On Thu, Jun 21, 2018 at 1:40 PM, Tim Hollebeek <[e-mail]>
wrote:

> So the disagreement is whether the it is sufficient to merely use the name
> for the
>
> DNS lookup, and then accept whatever happens afterwards, or whether the
> intent
>
> was that the web page should be retrieved in much the same way as it is
> retrieved by
>
> browsers.  Matching them as closely as possible makes the validation more
> reliable.
>

I think TLS-ALPN documents why this is true, but we know multiple CAs that
implemented either TLS-SNI or alternatives viewed it the same at the time.
I am greatly appreciative of hindsight being 20/20, but I think it's
important to recall that it is hindsight. As part of the introduction of
3.2.2.4.10, CAs were actively discussing about how this avoids the need to
do such matches, and the CA/Browser Forum Validation WG acknowledged it as
a correct interpretation. This is not about strict interpretations - this
is about documented and uncontested discussion in the Validation WG.

However, as to the remainder of the message, it seems we're echoing each
other - that a well-specified TLS-ALPN that concretely documents the
processing mode is of great benefit to the community, both in terms of
client implementers knowing what edge cases to expect that may cause an
ACME server to reject their response, and ACME servers to consider in
implementing when considering the validation level of the client's request.
My hope, then, is that any energy that might be directed at trying to
duplicate this work in 3.2.2.4.10 in the CA/Browser Forum might otherwise
be more productively and holistically directed at this effort within the
IETF and TLS-ALPN, allowing both broader participation and review, and
resulting in a state such that 3.2.2.4.10 can simply be replaced,
wholesale, with a statement "Using TLS-ALPN as specified is acceptable".


> Unfortunately, historically, the requirements are underspecified, and
> there is freedom
>
> to implement the validation mechanism badly.  There are improvements
>
> that were discussed in the excellent discussion in Virginia, but even
> today, we
>
> aren’t there yet.  So yes, it is possible by using a very strict,
> technical reading,
>
> an argument can be made that TLS-SNI is compliant.
>


>
>
> I’m just not a fan of that argument.  When the BRs say “retrieve a […] web
> page”, I
>
> believe that includes a responsibility to interpret that provision in a
> way that meets
>
> the intent of the validation method, and doesn’t introduce security risks.
>
>
>
> -Tim
>
>
>