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

[Tim Hollebeek <[e-mail]>]

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.

 

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

 

On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek <[e-mail] <mailto:[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.