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 messages. [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 constraint. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
