On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek <[email protected]> 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.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
