On Thu, Feb 22, 2018 at 05:48:23PM -0800, Roland Bracewell Shoemaker wrote:
> Hey all,
> After the issues with the SNI based TLS challenges were discovered
> there was interest from a number of parties in developing another
> challenge that did validation at the TLS layer. After some discussion
>  about possibilities we’ve come up with a new challenge type based on
> ALPN which we believe provides the required security properties which
> the SNI based methods did not have.
> I’ve attached the rough draft of a document which defines this new
> method and lays out the security considerations and design rationale
> for it. 
> Happy to field any questions about the details. 

If some hoster has indepent HTTP and HTTPS (some do) and such hoster
supports validating user certificates with this method, one can
hijack some HTTP name that does not have corresponding HTTPS name
(thanks to HSTS, and cookies are a lesser problem). Concerns about
such hosters were behind deprecating one GlobalSign validation method
involving test certificates (or else it was completely misunderstanding
the issue). However, even the HTTP validation method has issues with
hosters like this (there are problems also in other direction).

Also, this seems to aim for compliance for random value in certificate,
which I do not necressarily think is a good idea considering the amount
of issues with that method as described[1].

And as for implementability, this does look like something I could
implement in my TLS library (where requirement is to be able to
identify validation requests during ClientHello processing, and
validation request preferably not introducing new TLS messages[2]).
This method is identifiable such and does not introduce new TLS

[1] I have absolutely no reason to believe that issues with the
troublesome GlobalSign method where not due to fundamential
vulernabilities in the CABForum method they used. The random
value in certificate method has all the same concerns (plus
at least one bug unique to it... Fortunately this proposal
does not depend on that bug in any way).

[2] The latter is not hard constraint, it is just to avoid
having to write the pretty sizable chunk of code required to
alter the handshake state machine. The former is hard


Acme mailing list

Reply via email to