Re: [Acme] tls-alpn-01 spec: TLS-SNI history
On Thu, Jun 21, 2018 at 1:40 PM, Tim Hollebeek wrote: > 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. > I think TLS-ALPN documents why this is true, but we know multiple CAs that implemented either TLS-SNI or alternatives viewed it the same at the time. I am greatly appreciative of hindsight being 20/20, but I think it's important to recall that it is hindsight. As part of the introduction of 3.2.2.4.10, CAs were actively discussing about how this avoids the need to do such matches, and the CA/Browser Forum Validation WG acknowledged it as a correct interpretation. This is not about strict interpretations - this is about documented and uncontested discussion in the Validation WG. However, as to the remainder of the message, it seems we're echoing each other - that a well-specified TLS-ALPN that concretely documents the processing mode is of great benefit to the community, both in terms of client implementers knowing what edge cases to expect that may cause an ACME server to reject their response, and ACME servers to consider in implementing when considering the validation level of the client's request. My hope, then, is that any energy that might be directed at trying to duplicate this work in 3.2.2.4.10 in the CA/Browser Forum might otherwise be more productively and holistically directed at this effort within the IETF and TLS-ALPN, allowing both broader participation and review, and resulting in a state such that 3.2.2.4.10 can simply be replaced, wholesale, with a statement "Using TLS-ALPN as specified is acceptable". > 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 > > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] tls-alpn-01 spec: TLS-SNI history
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 mailto:tim.holleb...@digicert.com> > 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. smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] tls-alpn-01 spec: TLS-SNI history
> On Jun 21, 2018, at 10:53 AM, Ilari Liusvaara > wrote: > > On Thu, Jun 21, 2018 at 09:53:07AM -0400, Felipe Gasper wrote: > >> I would guess that the reason why Apache didn’t get much grief over >> TLS-SNI is that many--most?--hosting services require a certificate >> to match one or more domains on the associated Apache virtual host. >> But that’s not universal by any stretch. > > Also, getting the default virtual host on most hosting services is > probably not easy. And without default vhost, you can only answer to > names you have. At least one entity on every IP address has it. And it’s trivial for anyone to check to see who it is. -FG ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] tls-alpn-01 spec: TLS-SNI history
On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] tls-alpn-01 spec: TLS-SNI history
> 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). 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. 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. -Tim smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] tls-alpn-01 spec: TLS-SNI history
On Wed, Jun 20, 2018 at 5:34 AM, Ilari Liusvaara wrote: > > My understanding was that catastrophic problem was not the default- > vhost behavior of Apache or Nginx, altough that could casue security > issues. But instead, the problem was that many hosting provoders let > one claim arbitrary hostnames on FCFS basis. This let attacker upload > arbitrary validation certificates to be served, and due to how TLS-SNI > worked, this lead to misvalidation. > This is correct, although it was not necessarily dependent on FCFS behaviour - the issue would still exist because there was no implicit or explicit binding between the ACME challenge name and the name being validated in the protocol. That, combined with service providers reliance on DNS to resolve conflicts, lead to these issues. I'm not aware of any of the issues that were responsibly disclosed to browser vendors having been related to Apache configuration. > 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. > Note: The Baseline Requirements do not require this. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] tls-alpn-01 spec: TLS-SNI history
On Tue, Jun 19, 2018 at 08:30:32PM -0400, Felipe Gasper wrote: > Having read over the history of TLS-SNI as reported in the draft > spec, I feel like it might be prudent to mention that a > significant part of the failure of TLS-SNI was Apache httpd and > its (nonsensical, IMO) behavior of sending certificates for domains > that don’t match the SNI request. > > The write-up mentions “service providers”; for what it’s worth, I > feel like a more complete and accurate picture would also indicate > that “popular server software” (e.g., Apache … maybe others?) will > happily serve up a certificate that has no connection with the SNI > request, and that this is also a significant part of why TLS-SNI did > not work. My understanding was that catastrophic problem was not the default- vhost behavior of Apache or Nginx, altough that could casue security issues. But instead, the problem was that many hosting provoders let one claim arbitrary hostnames on FCFS basis. This let attacker upload arbitrary validation certificates to be served, and due to how TLS-SNI worked, this lead to misvalidation. 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. The TLS-SNI-01 included was default-vhost countermeasures, but those were dropped from TLS-SNI-02, and from what I can tell, were not actually used. -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] tls-alpn-01 spec: TLS-SNI history
Having read over the history of TLS-SNI as reported in the draft spec, I feel like it might be prudent to mention that a significant part of the failure of TLS-SNI was Apache httpd and its (nonsensical, IMO) behavior of sending certificates for domains that don’t match the SNI request. The write-up mentions “service providers”; for what it’s worth, I feel like a more complete and accurate picture would also indicate that “popular server software” (e.g., Apache … maybe others?) will happily serve up a certificate that has no connection with the SNI request, and that this is also a significant part of why TLS-SNI did not work. -Felipe Gasper Mississauga, ON ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
