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

[Ryan Sleevi <[e-mail]>]

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

>
> > TLS-ALPN addresses the latter problem by requiring the server_name to
> match
> > the validation target (which is AFACIT also required by the Baseline
> > Requirements). This stops claiming arbitary names from allowing
> > misvalidations.
>
> This was certainly the intent.  Never in over two years of some pretty
> detailed discussions about the mechanics of validation did anyone ever
> propose it was reasonable to validate domain name A by contacting
> the web server for a name that is not A (except for the approved the
> _prefix
> stuff).
>

That's not what is done under TLS-SNI.


> I realize that after it was pointed out that TLS-SNI was horribly broken
> in this regard, there were attempts by some to retroactively claim that
> such behavior was compliant, but I always found those explanations a
> bit tortured and unconvincing.  Certainly if I a large commercial CA had
> made them, they would have been laughed at and ridiculed.
>

Considering that large commercial CAs similarly interpreted the language as
described, I don't think this claim is well-supported. At the time of
TLS-SNI, it was seen as acceptable practice, and indeed, judging by the
minutes, CAs that similarly interpreted it as such were actively
participating in the validation WG and explicitly suggesting equivalent
solutions.


> I would actually love to work with some people on updating the CABF
> method 10 validation requirements in order to properly express the
> security requirements that ALPN-01 satisfies.  The whole TLS-SNI
> experience showed that Method 10 does not have sufficiently rigorous
> requirements to guarantee it actually validates what it claims to validate.
> Since the CABF VWG is currently working on adding more security rigor
> to all the approved validation methods, it would be a great time to fix
> up Method 10.
>
> ALPN-01 is a much better validation method, and I'm very thankful
> to all the people who worked hard to come up with a replacement,
> which as far as I can tell from looking at it briefly (I wish I had more
> time)
> looks pretty secure and robust.
>

I think it's good for CAs to look at improving validation requirements. I
think an easier way, however, than that attempt to describe prosaically
what TLS-ALPN expresses from guarantees is a simple and explicit
requirement to use TLS-ALPN. To that end, the question for TLS-ALPN spec is
whether it sufficiently expresses the expectations for where things go
right - and the handling mode for errors along the way. Thus, if there is
any time or energy for fixing Method 10, it seems that diverting it to
TLS-ALPN and ensuring it's well-specified in terms of failure handling and
expectations is the best way to achieve that laudable goal.