TLS-SNI-01 and compliance with BRs

[Doug Beattie]

Now that I'm more familiar with method 9 and 10 domain validation methods and heard a few side discussions about the topic, it's made me (and others) wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.

The BRs say:
3.2.2.4.10. TLS Using a Random Number
Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value within a Certificate on the Authorization Domain Name which is accessible by the CA via TLS over an Authorized Port.

But it's my understanding that the CA validates the presence of the random number on "random.acme.invalid" and not on the ADN specifically. Is the validation done by confirming the presence of a random number within the certificate on the ADN, or some other location? I'm probably misreading the ACME spec, but is sure seems like the validation is not being done on the ADN.

Doug

[Alex Gaynor]

I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
performs a DNS lookup for the ADN, connects to that IP, and initiatives a
TLS connection with the .acme.invalid SNI value.

Certificates don't exist on Domain Names if we think really hard about it,
but servers with IPs that domain names point to can serve certificates, and
that seems like a reasonable interpretation of the intent of that sentence,
which TLS-SNI-01 fulfills.

Alex

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Doug Beattie]

The point is, you don’t really connect to the Certificate on the Authorization Domain Name, you connect to a certificate on the same IP address as the ADN, but you actually intentionally ask for a different server name, which has no relationship to the ADN (except they happen to share the same IP address). It seems like misissuance to me.

From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Thursday, January 18, 2018 3:47 PM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: TLS-SNI-01 and compliance with BRs

I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01 performs a DNS lookup for the ADN, connects to that IP, and initiatives a TLS connection with the .acme.invalid SNI value.

Certificates don't exist on Domain Names if we think really hard about it, but servers with IPs that domain names point to can serve certificates, and that seems like a reasonable interpretation of the intent of that sentence, which TLS-SNI-01 fulfills.

Alex

On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
Now that I'm more familiar with method 9 and 10 domain validation methods and heard a few side discussions about the topic, it's made me (and others) wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.

The BRs say:
3.2.2.4.10. TLS Using a Random Number
Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value within a Certificate on the Authorization Domain Name which is accessible by the CA via TLS over an Authorized Port.

But it's my understanding that the CA validates the presence of the random number on "random.acme.invalid" and not on the ADN specifically. Is the validation done by confirming the presence of a random number within the certificate on the ADN, or some other location? I'm probably misreading the ACME spec, but is sure seems like the validation is not being done on the ADN.

Doug

_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Matthew Hardeman]

The trouble is that the BRs for those methods are really really vague.

I don't know that one can make a stronger case for misissuance versus
properly issued in these cases.

I'm certainly no fan of the mechanism in TLS-SNI-01 and regard it deficient
in the face of real world deployment circumstances. Clearly Let's Encrypt
does too, for why else would they have disabled the mechanism?

If we assume a world with more complex infrastructure, the case can be made
that they're not attaching to the authorization domain name, because they
failed to submit that name via SNI to the endpoint to which they are
attached, which may cause the validation to be routed incorrectly within
certain more complex hosting architectures. On the other hand, they did
access the right IP address via DNS lookup to the correct target
authorization domain name, meaning they're talking to the right endpoint at
the IP layer.

Nothing in the BRs makes clear what would be a correct interpretation.
It's hard to imagine that one could not defend that "on the Authorization
Domain Name" via TLS over an Authorized Port means no more than at an IP
address discovered as an A or AAAA record after having dereferenced the
authorization domain name as necessary via typical DNS resolution rules
(allowing for CNAME, etc.) on port 443.

Nowhere within the BRs is it formally specified that the TLS session over
which this validation is taking place need to even implement SNI (an
optional feature) much less that there should be regard for the value.

Having said all that, and having read the very limited specifications of
the 10 blessed methods, I have, as an outsider looking in, arrived at the
conclusion that each and every of these methods is ridiculously
underspecified. I'm convinced that each of the 10 should be scrutinized
thoroughly before being discarded or in the alternative formally specified
in egregious detail, such that questions such as this one may not be
raised.

[Matthew Hardeman]

On Thu, Jan 18, 2018 at 2:47 PM, Alex Gaynor via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> Certificates don't exist on Domain Names if we think really hard about it,
> but servers with IPs that domain names point to can serve certificates, and
> that seems like a reasonable interpretation of the intent of that sentence,
> which TLS-SNI-01 fulfills.
>
>

Expounding on that, certificate & key pairs are associated to logical end
points who mechanism of distinct selection can vary as to at least several
modes:

1. The TLS certificate & key pairs are bound to a combination of IP
address(es) and Port(s) such that any connection to said combination shall
definitively present a particular certificate.
2a. The TLS certificate & key pair selection matrix may add a further
decisioning axis dependent upon the presentation of a TLS-SNI value.
2b. There may be a behavior selecting for a default TLS certificate & key
pair in circumstances where a TLS-SNI is presented but does not match a
configured pattern.
2c. There may be a behavior selecting for a default TLS certificate upon
the failure to present a TLS-SNI value.

There are probably more. In fact, as I think of it, I am certain this is
the case. Some of the TLS termination load balancers at the CDNs use other
early protocol and alg support information in the TLS exchange to decide to
present an ECC certificate versus an RSA certificate dynamically.
Similarly, some of the same players utilize alg support in the exchange to
serve up a "legacy" sha-1 certificate signed by a legacy trusted CA
hierarchy that would no longer be trusted in modern browsers in order to
provide legacy compatibility.

These kinds of scenarios conspire to make domain validation via TLS
connection quite nebulous as to whether or not you can ascertain that you
are communicating with the party you intend to validate.

As Mr. Gaynor points out, there remains the reasonable interpretation that
the mechanism undertaken by TLS-SNI-01 does fulfill the quite vague mandate
of method 10. Naturally, there is also a reasonable interpretation that
the mechanism does not satisfy the intent of method 10. Because method 10
is construed in such a technologically deficient manner, who could
reasonably say?

[J.C. Jones]

As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
through it in the Validation Working Group. The ADN lookup is DNS, and what
you find when you connect there via TLS, within the certificate, should be
the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
TLS-SNI-01 while being generic enough to permit CAs to accomplish the same
general validation structure without following the ACME-specified algorithm.

J.C.

On Thu, Jan 18, 2018 at 1:47 PM, Alex Gaynor via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
> performs a DNS lookup for the ADN, connects to that IP, and initiatives a
> TLS connection with the .acme.invalid SNI value.
>

> Certificates don't exist on Domain Names if we think really hard about it,
> but servers with IPs that domain names point to can serve certificates, and
> that seems like a reasonable interpretation of the intent of that sentence,
> which TLS-SNI-01 fulfills.
>

> Alex

>
> On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > Now that I'm more familiar with method 9 and 10 domain validation methods
> > and heard a few side discussions about the topic, it's made me (and
> others)
> > wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.
> >
> > The BRs say:
> > 3.2.2.4.10. TLS Using a Random Number
> > Confirming the Applicant's control over the FQDN by confirming the

> > presence of a Random Value within a Certificate on the Authorization
> Domain

> > Name which is accessible by the CA via TLS over an Authorized Port.
> >
> > But it's my understanding that the CA validates the presence of the
> random
> > number on "random.acme.invalid" and not on the ADN specifically. Is the
> > validation done by confirming the presence of a random number within the
> > certificate on the ADN, or some other location? I'm probably misreading
> > the ACME spec, but is sure seems like the validation is not being done on
> > the ADN.
> >
> > Doug
> >
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://lists.mozilla.org/listinfo/dev-security-policy

> >
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Matthew Hardeman]

On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
> through it in the Validation Working Group. The ADN lookup is DNS, and what
> you find when you connect there via TLS, within the certificate, should be
> the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
> TLS-SNI-01 while being generic enough to permit CAs to accomplish the same
> general validation structure without following the ACME-specified
> algorithm.
>
> J.C.

I would presume that the CABforum would be the place to explore further
details, but it seems that the specifications for the #10 method should be
reexamined as to what assurances they actually provide with a view to
revising those specifications. At least 1 CA so far has found that the
real world experience of a (presumably) compliant application of method #10
as it exists today was deficient in mitigating the provision of
certificates to incorrect/unauthorized parties.

[J.C. Jones]

That would be the right place. At the time there was not universal desire
for these validation mechanisms to be what I'd call 'fully specified'; the
point of having them written this way was to leave room for individuality
in meeting the requirements.

Of course, having a few carefully-specified-and-validated mechanisms
instead of individuality has worked rather well for other security-critical
operations, like the very transport security this whole infrastructure
exists to support. Perhaps that argument could be re-opened.

J.C.


On Thu, Jan 18, 2018 at 3:25 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

[Ryan Hurst]

> I would presume that the CABforum would be the place to explore further
> details, but it seems that the specifications for the #10 method should be
> reexamined as to what assurances they actually provide with a view to
> revising those specifications. At least 1 CA so far has found that the
> real world experience of a (presumably) compliant application of method #10
> as it exists today was deficient in mitigating the provision of
> certificates to incorrect/unauthorized parties.

I agree CABFORUM seems to be the right place to get this text clarified.

More concretely I have recently re-reviewed the validation methods and in general, think they most need fairly significant clarification.

[Ryan Sleevi]

I think others have already responded, but I do want to highlight one other
problem with the reasoning being offered here: SNI is not mandatory in TLS.
It's an extension (RFC 6066) that is optional.

More concretely, Methods .6, .8, .9, and .10 are all effectively
demonstrations over the IP address pointed to by a domain - rather than the
domain itself. I mention .6 in there because there is, for example, no
requirement to use a "Host" header - you could use HTTP/1.0 (as some CAs,
I'm told, do).

Similarly, one can read that .10 doesn't actually require the TLS handshake
to complete, nor for a ServerKeyExchange to be in any way related to the
Certificate. It is, for example, sufficient merely to send a Client Hello
and Server Hello+Certificate and terminate the connection.

This is the challenge of defining validation methods in the abstract,
rather than with concrete specifications. The ACME specification is useful
in it's the first attempt I'm aware of that attempts to fully, normatively
specify how to validate assurances in an open and interoperable way. The
historic ambiguities derived from the BRs, working in abstract,
technology-neutral ways, necessarily leads to these sorts of contrived
scenarios. For example, .7 doesn't demonstrate control over an ADN - in as
much as it allows control over a subdomain of an ADN to be treated as
control over the ADN itself (if it has a leading prefix). .9 doesn't
require the domain name appear within the Test Certificate - similar to the
point being raised here about the domain name not appearing within the TLS
handshake for .10.

On Thu, Jan 18, 2018 at 4:46 PM, Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> The point is, you don’t really connect to the Certificate on the
> Authorization Domain Name, you connect to a certificate on the same IP
> address as the ADN, but you actually intentionally ask for a different
> server name, which has no relationship to the ADN (except they happen to
> share the same IP address). It seems like misissuance to me.
>
>

> From: Alex Gaynor [mailto:aga...@mozilla.com]
> Sent: Thursday, January 18, 2018 3:47 PM
> To: Doug Beattie <doug.b...@globalsign.com>
> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: TLS-SNI-01 and compliance with BRs
>

> I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
> performs a DNS lookup for the ADN, connects to that IP, and initiatives a
> TLS connection with the .acme.invalid SNI value.
>
> Certificates don't exist on Domain Names if we think really hard about it,
> but servers with IPs that domain names point to can serve certificates, and
> that seems like a reasonable interpretation of the intent of that sentence,
> which TLS-SNI-01 fulfills.
>
> Alex
>
> On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <

> dev-secur...@lists.mozilla.org<mailto:dev-

> securit...@lists.mozilla.org>> wrote:
> Now that I'm more familiar with method 9 and 10 domain validation methods
> and heard a few side discussions about the topic, it's made me (and others)
> wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.
>
> The BRs say:
> 3.2.2.4.10. TLS Using a Random Number
> Confirming the Applicant's control over the FQDN by confirming the
> presence of a Random Value within a Certificate on the Authorization Domain
> Name which is accessible by the CA via TLS over an Authorized Port.
>
> But it's my understanding that the CA validates the presence of the random
> number on "random.acme.invalid" and not on the ADN specifically. Is the
> validation done by confirming the presence of a random number within the
> certificate on the ADN, or some other location? I'm probably misreading
> the ACME spec, but is sure seems like the validation is not being done on
> the ADN.
>
> Doug
>
> _______________________________________________
> dev-security-policy mailing list

> dev-secur...@lists.mozilla.org<mailto:dev-
> securit...@lists.mozilla.org>

[Tim Hollebeek]

My recollection is that there were a number of CA/B forum participants
(including me) who asked repeatedly if method #10 could be expanded
beyond a single sentence.

I don't remember anyone speaking up in opposition, just silence.

I continue to support making sure that all of the validation methods have
enough detail so that their security properties can be fully analyzed.
Hopefully that would help avoid incidents like this in the future.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of J.C.
Jones
> via dev-security-policy
> Sent: Thursday, January 18, 2018 3:34 PM
> To: Matthew Hardeman <mhar...@gmail.com>
> Cc: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-security-
> pol...@lists.mozilla.org; Alex Gaynor <aga...@mozilla.com>
> Subject: Re: TLS-SNI-01 and compliance with BRs
>

> > I would presume that the CABforum would be the place to explore
> > further details, but it seems that the specifications for the #10
> > method should be reexamined as to what assurances they actually
> > provide with a view to revising those specifications. At least 1 CA
> > so far has found that the real world experience of a (presumably)
> > compliant application of method #10 as it exists today was deficient
> > in mitigating the provision of certificates to incorrect/unauthorized
parties.
> >

[Doug Beattie]

I think we’ve gotten off track. While the general discussion is good and we need to update the validation methods to provide more precise details, I want to get back to the point in hand which is asking if the ACME TLS-SNO-01 method is compliant with method 10. If method 10 specified that you could validate the random number at the same IP address as the SAN being validated, then it would have said that. How does validating the “Random Value within a Certificate on the IP address of the Authorization Domain Name” comply with validating the “Random Value within a Certificate on the Authorization Domain Name”? The TLS-SNI method specifically directs the CA to check for the random number on a location other than the ADN.


Many CA’s haven’t complied with the Mozilla requirement to list the methods they use (including Google btw), so it’s hard to tell which CAs are using method 10. Of the CA CPSs I checked, only Symantec has method 10 listed, and with the DigiCert acquisition, it’s not clear if that CPS is still active. We should find out on January 31st who else uses it.

In the meantime, we should ban anyone from using TLS-SNI as a non-compliant implementation, even outside shared hosting environments. There could well be other implementations that comply with method 10, so I’m not suggesting we remove that from the BRs yet (those that don’t allow SNI when validating the presence of the random number within the certificate of a TLS handshake are better).

Regarding the comment on the ACME protocol: “The ACME specification is useful in it's the first attempt I'm aware of that attempts to fully, normatively specify how to validate assurances in an open and interoperable way.” Yes, open review of the protocol was good. As you are likely aware, the specification points out [1] vulnerabilities with the use of ACME by hosting providers “The use of hosting providers is a particular risk for ACME validation.” It appears that the detailed analysis into these risks wasn’t performed or considered prior to using ACME. If the analysis was done the risk mitigation wasn’t documented in spec.


Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai, Cisco, EFF, OVH and Chrome) using TLS-SNI-01? I only call them out because as large financial supports, they may be more incentivized to use it than others.

Personally, I think the use of TLS-SNI-01 should be banned immediately, globally (not just by Let’s Encrypt), but without knowing which CAs use it, it’s difficult to enforce.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, January 18, 2018 7:25 PM
To: Doug Beattie <doug.b...@globalsign.com>

Cc: Alex Gaynor <aga...@mozilla.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: TLS-SNI-01 and compliance with BRs

I think others have already responded, but I do want to highlight one other problem with the reasoning being offered here: SNI is not mandatory in TLS. It's an extension (RFC 6066) that is optional.

More concretely, Methods .6, .8, .9, and .10 are all effectively demonstrations over the IP address pointed to by a domain - rather than the domain itself. I mention .6 in there because there is, for example, no requirement to use a "Host" header - you could use HTTP/1.0 (as some CAs, I'm told, do).

Similarly, one can read that .10 doesn't actually require the TLS handshake to complete, nor for a ServerKeyExchange to be in any way related to the Certificate. It is, for example, sufficient merely to send a Client Hello and Server Hello+Certificate and terminate the connection.

This is the challenge of defining validation methods in the abstract, rather than with concrete specifications. The ACME specification is useful in it's the first attempt I'm aware of that attempts to fully, normatively specify how to validate assurances in an open and interoperable way. The historic ambiguities derived from the BRs, working in abstract, technology-neutral ways, necessarily leads to these sorts of contrived scenarios. For example, .7 doesn't demonstrate control over an ADN - in as much as it allows control over a subdomain of an ADN to be treated as control over the ADN itself (if it has a leading prefix). .9 doesn't require the domain name appear within the Test Certificate - similar to the point being raised here about the domain name not appearing within the TLS handshake for .10.

On Thu, Jan 18, 2018 at 4:46 PM, Doug Beattie via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
The point is, you don’t really connect to the Certificate on the Authorization Domain Name, you connect to a certificate on the same IP address as the ADN, but you actually intentionally ask for a different server name, which has no relationship to the ADN (except they happen to share the same IP address). It seems like misissuance to me.

From: Alex Gaynor [mailto:aga...@mozilla.com<mailto:aga...@mozilla.com>]
Sent: Thursday, January 18, 2018 3:47 PM

To: Doug Beattie <doug.b...@globalsign.com<mailto:doug.b...@globalsign.com>>
Cc: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: TLS-SNI-01 and compliance with BRs

I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01 performs a DNS lookup for the ADN, connects to that IP, and initiatives a TLS connection with the .acme.invalid SNI value.

Certificates don't exist on Domain Names if we think really hard about it, but servers with IPs that domain names point to can serve certificates, and that seems like a reasonable interpretation of the intent of that sentence, which TLS-SNI-01 fulfills.

Alex

On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org><mailto:dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>>> wrote:
Now that I'm more familiar with method 9 and 10 domain validation methods and heard a few side discussions about the topic, it's made me (and others) wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.

The BRs say:
3.2.2.4.10. TLS Using a Random Number
Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value within a Certificate on the Authorization Domain Name which is accessible by the CA via TLS over an Authorized Port.

But it's my understanding that the CA validates the presence of the random number on "random.acme.invalid" and not on the ADN specifically. Is the validation done by confirming the presence of a random number within the certificate on the ADN, or some other location? I'm probably misreading the ACME spec, but is sure seems like the validation is not being done on the ADN.

Doug

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org><mailto:dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>>
https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

On Fri, Jan 19, 2018 at 10:22 AM, Doug Beattie <doug.b...@globalsign.com>
wrote:

>
>
> I think we’ve gotten off track. While the general discussion is good and

> we *need* to update the validation methods to provide more precise

> details, I want to get back to the point in hand which is asking if the
> ACME TLS-SNO-01 method is compliant with method 10. If method 10 specified
> that you could validate the random number at the same IP address as the SAN
> being validated, then it would have said that.
>

I find your faith in the CA/Browser Forum's technical ability disturbing,
given the evidence.

I don't think it's off track to point out that it's the same level of
assurance as .6, .8, and .9.

> How does validating the “Random Value within a Certificate on the IP
> address of the Authorization Domain Name” comply with validating the
> “Random Value within a Certificate on the Authorization Domain Name”? The
> TLS-SNI method specifically directs the CA to check for the random number

> on a location *other than* the ADN.
>

No, that's not correct. You're attempting to define a usage of the protocol
(TLS) that is not actually mandatory, in order to support the objection -
yet as pointed out, neither the BRs nor the relevant specification (TLS)
support that reading, nor do the other methods.

> Many CA’s haven’t complied with the Mozilla requirement to list the
> methods they use (including Google btw), so it’s hard to tell which CAs are
> using method 10. Of the CA CPSs I checked, only Symantec has method 10
> listed, and with the DigiCert acquisition, it’s not clear if that CPS is
> still active. We should find out on January 31st who else uses it.
>
>
>
> In the meantime, we should ban anyone from using TLS-SNI as a
> non-compliant implementation, even outside shared hosting environments.
> There could well be other implementations that comply with method 10, so
> I’m not suggesting we remove that from the BRs yet (those that don’t allow
> SNI when validating the presence of the random number within the
> certificate of a TLS handshake are better).
>

Your analysis is flawed, ergo your conclusions are derived from flawed
reasoning.

>
>
> Regarding the comment on the ACME protocol: “The ACME specification is
> useful in it's the first attempt I'm aware of that attempts to fully,
> normatively specify how to validate assurances in an open and interoperable
> way.” Yes, open review of the protocol was good. As you are likely aware,
> the specification points out [1] vulnerabilities with the use of ACME by
> hosting providers “The use of hosting providers is a particular risk for
> ACME validation.” It appears that the detailed analysis into these risks
> wasn’t performed or considered prior to using ACME. If the analysis was
> done the risk mitigation wasn’t documented in spec.
>
>
>
>
>
> Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai,
> Cisco, EFF, OVH and Chrome) using TLS-SNI-01? I only call them out because
> as large financial supports, they may be more incentivized to use it than
> others.
>
>
>
> Personally, I think the use of TLS-SNI-01 should be banned immediately,
> globally (not just by Let’s Encrypt), but without knowing which CAs use it,
> it’s difficult to enforce.
>

While your reasons are incorrect on multiple technical dimensions, you are
correct that we want to see an immediate cessation of _any_ use of the .9
and .10 methods, and then evaluate on a case by case basis the mitigating
factors and risks that may necessitate a gradual phase out on a per-CA
basis.


>
>
> [1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2
>
>
>
>
>
> *From:* Ryan Sleevi [mailto:ry...@sleevi.com]
> *Sent:* Thursday, January 18, 2018 7:25 PM
> *To:* Doug Beattie <doug.b...@globalsign.com>
> *Cc:* Alex Gaynor <aga...@mozilla.com>; mozilla-dev-security-policy@
> lists.mozilla.org
>
> *Subject:* Re: TLS-SNI-01 and compliance with BRs

> dev-secur...@lists.mozilla.org> wrote:
>
> The point is, you don’t really connect to the Certificate on the
> Authorization Domain Name, you connect to a certificate on the same IP
> address as the ADN, but you actually intentionally ask for a different
> server name, which has no relationship to the ADN (except they happen to
> share the same IP address). It seems like misissuance to me.
>
>
> From: Alex Gaynor [mailto:aga...@mozilla.com]
> Sent: Thursday, January 18, 2018 3:47 PM
> To: Doug Beattie <doug.b...@globalsign.com>
> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: TLS-SNI-01 and compliance with BRs
>
> I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
> performs a DNS lookup for the ADN, connects to that IP, and initiatives a
> TLS connection with the .acme.invalid SNI value.
>
> Certificates don't exist on Domain Names if we think really hard about it,
> but servers with IPs that domain names point to can serve certificates, and
> that seems like a reasonable interpretation of the intent of that sentence,
> which TLS-SNI-01 fulfills.
>
> Alex
>
> On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
> dev-secur...@lists.mozilla.org<mailto:dev-

> securit...@lists.mozilla.org>> wrote:
> Now that I'm more familiar with method 9 and 10 domain validation methods
> and heard a few side discussions about the topic, it's made me (and others)
> wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.
>
> The BRs say:
> 3.2.2.4.10. TLS Using a Random Number
> Confirming the Applicant's control over the FQDN by confirming the
> presence of a Random Value within a Certificate on the Authorization Domain
> Name which is accessible by the CA via TLS over an Authorized Port.
>
> But it's my understanding that the CA validates the presence of the random
> number on "random.acme.invalid" and not on the ADN specifically. Is the
> validation done by confirming the presence of a random number within the
> certificate on the ADN, or some other location? I'm probably misreading
> the ACME spec, but is sure seems like the validation is not being done on
> the ADN.
>
> Doug
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org<mailto:dev-

> securit...@lists.mozilla.org>

>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>

[Peter Bowen]

> On Jan 19, 2018, at 7:22 AM, Doug Beattie via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Many CA’s haven’t complied with the Mozilla requirement to list the methods they use (including Google btw), so it’s hard to tell which CAs are using method 10. Of the CA CPSs I checked, only Symantec has method 10 listed, and with the DigiCert acquisition, it’s not clear if that CPS is still active. We should find out on January 31st who else uses it.
>
> In the meantime, we should ban anyone from using TLS-SNI as a non-compliant implementation, even outside shared hosting environments. There could well be other implementations that comply with method 10, so I’m not suggesting we remove that from the BRs yet (those that don’t allow SNI when validating the presence of the random number within the certificate of a TLS handshake are better).

[snip]

> Personally, I think the use of TLS-SNI-01 should be banned immediately, globally (not just by Let’s Encrypt), but without knowing which CAs use it, it’s difficult to enforce.

Doug,

I don’t agree that TLS-SNI-01 should be banned immediately, globally. Amazon does not use TLS-SNI-01 today, so it would not directly impact Amazon operations.

I think we need to look back to the Mozilla Root Store Policy. The relevant portions are:

"2.1 CA Operations

prior to issuing certificates, verify certificate requests in a manner that we deem acceptable for the stated purpose(s) of the certificates;

2.2 Validation Practices
We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements:

For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the 10 methods documented in section 3.2.2.4 of version 1.4.1 (and not any other version) of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. Even if the current version of the BRs contains a method 3.2.2.4.11, CAs are not permitted to use this method.”

While this clearly does call out that the methods are acceptable, it isn’t a results oriented statement. The BRs also do not have clear results requirements for validation methods.

What does Mozilla expect to be verified? We know the 10 methods allow issuance where "the applicant has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf” is not true.

I think the next step should be for Mozilla to clearly lay out the requirements for CAs and then the validation methods can be compared to see if they met the bar.

Thanks,
Peter

[Jakob Bohm]

The following discussion is only a sketched out idea and thus does not
classify all the 10 blessed methods:


One rule that could reasonably be added to the BR or Mozilla
requirements for the various methods could be this general safety rule:

- Validation methods that check control over a single address (such as
certificate responses, well-known URLs etc.) are only valid for the
single name validated, not as proof of domain control. Thus they
cannot be used to validate control of an entire DNS zone, and thus is
not sufficient for preauthorizing certs for subdomains, nor for
getting wildcard certificates.

So for example, TLS-SNI-01 at best validates control of the requested
DNS name, possibly only of the used acme.invalid name.

In contrast the GlobalSign certificate method (as summarized in previous
posts here, I have not validated their exact procedures) apparently
validates the response for a specific name as both A/AAAA recond and SNI
name, and then takes this as proof of only that single name. (There was
some talk of wildcard use, which would not be OK under the stricter rule
above).

Examples of automatic validation methods good enough for proving full
zone control, as needed for wildcard certs or preauthorizing further
issuance would be DNS control over the zone apex, being the registrant
listed in whois or receiving e-mails for hostm...@zoneapex.example.

For e-mail certificates (no current BR rules, only root program specific
rules), ability to receive emails for exa...@example.com validates (at
class 1 level) control of that one e-mail address. While control of
postm...@example.com or hostm...@example.com or the DNS for
example.com validates (at class 1 level) control of all @example.com
e-mail addresses unless example.com is on the e-mail equivalent of a
public-suffix list. (Thus postm...@hotmail.com can't get certificates
for all the users without directly violating the sanctity of the e-mail
accounts).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Matthew Hardeman]

On Fri, Jan 19, 2018 at 9:22 AM, Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> I think we’ve gotten off track. While the general discussion is good and
> we need to update the validation methods to provide more precise details, I
> want to get back to the point in hand which is asking if the ACME
> TLS-SNO-01 method is compliant with method 10. If method 10 specified that
> you could validate the random number at the same IP address as the SAN
> being validated, then it would have said that. How does validating the
> “Random Value within a Certificate on the IP address of the Authorization
> Domain Name” comply with validating the “Random Value within a Certificate
> on the Authorization Domain Name”? The TLS-SNI method specifically directs
> the CA to check for the random number on a location other than the ADN.
>
>

I think many parties have made quite clear that the level of description in
BR method #10 covers a lot of possibilities, but there is insufficient
technical description in the method to call TLS-SNI-01. Indeed, it appears
from discussions prior that BR method #10 was engineered to incorporate
sufficient flexibility for TLS-SNI-01 as well as some other mechanisms.
Part of the trouble is "on the Authorization Domain Name" doesn't mean
anything specific.

>
> Many CA’s haven’t complied with the Mozilla requirement to list the
> methods they use (including Google btw), so it’s hard to tell which CAs are
> using method 10. Of the CA CPSs I checked, only Symantec has method 10
> listed, and with the DigiCert acquisition, it’s not clear if that CPS is
> still active. We should find out on January 31st who else uses it.
>
> In the meantime, we should ban anyone from using TLS-SNI as a
> non-compliant implementation, even outside shared hosting environments.
> There could well be other implementations that comply with method 10, so
> I’m not suggesting we remove that from the BRs yet (those that don’t allow
> SNI when validating the presence of the random number within the
> certificate of a TLS handshake are better)

I think reliance upon TLS-SNI-01 should cease in the general case. The
cause for which it should be rejected is because reliance strictly upon
TLS-SNI-01 is clearly demonstrated to yield a perverse consequence:
issuance of certificates to parties other than those who should be able to
receive them. However, there is simultaneously a quite reasonable argument
that the TLS-SNI-01 method is fully compliant with BR method #10. This
means the deficiency is in BR method #10, not strictly in TLS-SNI-01. I
would submit that if complying with BR method #10 were the sole goal,
TLS-SNI-01 achieved and continues to achieve that. And yet, clearly
TLS-SNI-01 can not be used for trust in the real world. In fact, as now
specified, BR method #10 can not be used for trust in the real world.

As to any mechanism of implementing BR method #10 without reliance on SNI,
there is an equally strong case to be made that not relying on SNI is
getting you a different web context in many shared hosting environments
than specifying the correct ADN in the SNI would. That, in turn, is
equally capable of causing issuance to parties other than intended. You
can not have it both ways. If method #10 is violated by sending the wrong
SNI value, an equally good argument exists that sending no SNI value at all
is also in violation. The fact of the matter is that method #10 specifies
none of this, so it's all fair game. Because method #10 is a vacuous
one-liner, there can be no reasonable support for compliance/non-compliance
on a concept that method #10 does not even touch on.

>
> Regarding the comment on the ACME protocol: “The ACME specification is
> useful in it's the first attempt I'm aware of that attempts to fully,
> normatively specify how to validate assurances in an open and interoperable
> way.” Yes, open review of the protocol was good. As you are likely aware,
> the specification points out [1] vulnerabilities with the use of ACME by
> hosting providers “The use of hosting providers is a particular risk for
> ACME validation.” It appears that the detailed analysis into these risks
> wasn’t performed or considered prior to using ACME. If the analysis was
> done the risk mitigation wasn’t documented in spec.
>

I concur that the evidence strongly suggests that the ACME working group
did an insufficient job of researching and documenting realities in
real-world deployment of website hosting environments, which is
disingenuous for those building a protocol to secure the issuance of PKI
certificates whose overwhelmingly prevalent use is the authentication and
encryption of web site traffic.

>
>
> Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai,
> Cisco, EFF, OVH and Chrome) using TLS-SNI-01? I only call them out because
> as large financial supports, they may be more incentivized to use it than
> others.
>

This question seems rather inappropriate. By all appearances, TLS-SNI-01
is arguably compliant with BR method #10. If mitigations at partner
hosting infrastructure are in place and functional, the issuance utilizing
TLS-SNI-01 is secure for those parties. Let's not forget: the
administration of ANY shared hosting infrastructure could successfully
validate by any non-DNS method as they've been trusted by their clients to
host their websites... If Let's Encrypt has worked with certain partners
to ensure that there's not an unknown security risk allowing for TLS-SNI-01
to be abused by outsiders, where is the problem?

[Matthew Hardeman]

One opinion I'd like to add to the discussion...

In as far as that at this point, it looks like it's time for guidance from
the root programs officially on whether or not and under what circumstances
TLS-SNI-01 and/or any other mechanism based on method #10 are allowable
moving forward....

I'd like to point out that both Let's Encrypt recognized an issue and
voluntarily disclosed and took measures in the direction of securing the
WebPKI above and beyond any demands made of them.

Additionally, GlobalSign was obviously diligent in their responsibility to
monitor this mailing list and others and actively discern whether any
ongoing discussion may pertain to their operations. As evidenced by their
preemptive disclosure and shut down of their method #10 validation
mechanism, they've shown strong adherence to the best practices espoused by
this community -- actively monitoring the broad discussions and concerns
and actively considering the impact of the issues surfaced in terms of
their own CA operations.

Ultimately, if it should arise that other CAs who rely on mechanisms
implementing or claiming to implement method #10 have similar risk and
vulnerabilities, those CAs should be called to task for not having timely
disclosed and remediated. Further, perhaps those CAs should suffer the
burden of mandatory revalidation under a different mechanism, as the
vulnerability category has now been acknowledged in the community for some
time and the recent press has been significant.

In contrast, I think any remediation plan should reward Let's Encrypt and
GlobalSign for their diligence and compliance to best practice.

[Ryan Sleevi]

On Fri, Jan 19, 2018 at 1:44 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

> Ultimately, if it should arise that other CAs who rely on mechanisms
> implementing or claiming to implement method #10 have similar risk and
> vulnerabilities, those CAs should be called to task for not having timely
> disclosed and remediated. Further, perhaps those CAs should suffer the
> burden of mandatory revalidation under a different mechanism, as the
> vulnerability category has now been acknowledged in the community for some
> time and the recent press has been significant.
>
> In contrast, I think any remediation plan should reward Let's Encrypt and
> GlobalSign for their diligence and compliance to best practice.
>

I disagree with this notion of 'rewarding' some CAs by letting the first to
disclose be allowed to continue to use methods that put users at risk.
Global user trust is not a 'reward', and removing that trust is not a
'punishment' - it is a calculation of risks based on available and
mitigating factors.

Framing it as 'reward' or 'punishment' unduly manipulates the discussion,
because it suggests the notion of favorability / unfavorability, when the
reality is that it's an objective evaluation across a multitude of
dimensions.

Should those who have not come forward be called to task? Yes. Because
they're ignoring industry best practice and they should revoke all of their
certs due to the 'unacceptable risk' clause. That's not a punishment.
That's mitigation based on the available information (i.e. none, for those
that didn't self-disclose)

[Doug Beattie]

Matthew,

That’s a good summary. It seems we have 2 methods that can be used only if the CAs using the methods have the design and risk mitigation factors reviewed and approved. It’s basically the old “any other method”, except before you can use it, the Root programs must review the design/implementation and can approve/reject them on a case by case basis. Is that where we are with these methods – Not approved unless disclosed and reviewed?

Given this discussion, there must be no other CAs using method 9 or 10, else they would have come forward by now with disclosures and have demonstrated their compliance.. Maybe we need to post this on the CABF public list?

Based on this, do we need a ballot to remove them from the BRs, or put in a statement in them to the effect that they can be used only if approved by Google on this list? I’m not picking on Ryan, but he’s the only root program representative that has expressed strong views on what is permitted and what is not (else you have your CA revoked or root pulled from the program).

Doug

From: Matthew Hardeman [mailto:mhar...@gmail.com]
Sent: Friday, January 19, 2018 1:45 PM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: ry...@sleevi.com; Alex Gaynor <aga...@mozilla.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: TLS-SNI-01 and compliance with BRs

One opinion I'd like to add to the discussion...

In as far as that at this point, it looks like it's time for guidance from the root programs officially on whether or not and under what circumstances TLS-SNI-01 and/or any other mechanism based on method #10 are allowable moving forward....

I'd like to point out that both Let's Encrypt recognized an issue and voluntarily disclosed and took measures in the direction of securing the WebPKI above and beyond any demands made of them.

Additionally, GlobalSign was obviously diligent in their responsibility to monitor this mailing list and others and actively discern whether any ongoing discussion may pertain to their operations. As evidenced by their preemptive disclosure and shut down of their method #10 validation mechanism, they've shown strong adherence to the best practices espoused by this community -- actively monitoring the broad discussions and concerns and actively considering the impact of the issues surfaced in terms of their own CA operations.

[Matthew Hardeman]

I concur that framing as reward versus punishment was not right.

No where did I meant to imply that early actors should get a free pass in
as far as continuing unmitigated validation using a vulnerable validation
method.

The early discoverers and those who reacted early to the vulnerability and
stopped validating have a natural protection of mass attacks upon the issue
becoming prevalently known. As such, perhaps those who reacted quickly and
earlier than others have the advantage of not needing explicit revalidation
for those validations which were compliant -- at least validations up to a
given time point.

Perhaps those who later reveal their reliance on these methods have higher
burdens of remediation, owing to the natural risk that occurs from being
vulnerable for extended time after significant publication of the issue and
owing to the overall risks evidenced by slow reaction to the initial
reports?

On Fri, Jan 19, 2018 at 1:23 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> On Fri, Jan 19, 2018 at 1:44 PM, Matthew Hardeman <mhar...@gmail.com>
> wrote:
>

>> Ultimately, if it should arise that other CAs who rely on mechanisms
>> implementing or claiming to implement method #10 have similar risk and
>> vulnerabilities, those CAs should be called to task for not having timely
>> disclosed and remediated. Further, perhaps those CAs should suffer the
>> burden of mandatory revalidation under a different mechanism, as the
>> vulnerability category has now been acknowledged in the community for some
>> time and the recent press has been significant.
>>
>> In contrast, I think any remediation plan should reward Let's Encrypt and
>> GlobalSign for their diligence and compliance to best practice.
>>
>

[Wayne Thayer]

Peter,

On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> What does Mozilla expect to be verified? We know the 10 methods allow
> issuance where "the applicant has registered the domain(s) referenced in
> the certificate or has been authorized by the domain registrant to act on
> their behalf” is not true.
>

> Will you describe a few examples of this?

I think the next step should be for Mozilla to clearly lay out the
> requirements for CAs and then the validation methods can be compared to see
> if they met the bar.
>

> Are you asking Mozilla to clarify these two potentially contradictory
statements in our policy? Or something more?

Thanks,

Wayne

[Matthew Hardeman]

On Fri, Jan 19, 2018 at 11:06 AM, Peter Bowen via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
>
> For a certificate capable of being used for SSL-enabled servers, the CA

> must ensure that the applicant has registered the domain(s) referenced in

> the certificate or has been authorized by the domain registrant to act on

> their behalf. This must be done using one or more of the 10 methods
> documented in section 3.2.2.4 of version 1.4.1 (and not any other version)
> of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly
> specify the procedure(s) that the CA employs, and each documented procedure
> should state which subsection of 3.2.2.4 it is complying with. Even if the
> current version of the BRs contains a method 3.2.2.4.11, CAs are not
> permitted to use this method.”
>
> While this clearly does call out that the methods are acceptable, it isn’t
> a results oriented statement. The BRs also do not have clear results
> requirements for validation methods.
>

> What does Mozilla expect to be verified? We know the 10 methods allow
> issuance where "the applicant has registered the domain(s) referenced in
> the certificate or has been authorized by the domain registrant to act on
> their behalf” is not true.
>
>

I also think it may make sense for the root program policy to illuminate
specifically the nature and parameters of a successful outcome.

Maybe it's something like:

The validation is properly achieved when it 1) aligns to one of the
permitted BR validation mechanisms AND 2) successfully achieves the various
other goals that the program has. Things like "provides reasonable
assurance that the issuance will be granted only to a party demonstrating
ownership or effective control of the related domain".

It's not clear today, absent further guidance, that the Mozilla root
program policy would call on a CA to preemptively stop utilizing a
compromised mechanism which is BR compliant prior to change of the BR. If
the program were changed such that one of the outcomes to be considered at
the time of the validation is that the CA, via technical means, has strong
assurance that the issuance is to a party owning or controlling the domain
in question, then a publication of a vulnerability over a certain
validation method would certainly strike the CA's confidence in that
assertion and so guide that the validation can not be considered proper for
reliance for issuance.

Incorporating intended outcomes of the policies related to validation and
issuance pursuant to validations may be helpful in providing a default,
"automatic" guidance on how to handle an emerging vulnerability of a
previously acceptable method.

[Ryan Sleevi]

On Fri, Jan 19, 2018 at 3:58 PM Doug Beattie <doug.b...@globalsign.com>
wrote:

> Matthew,
>
>
>
> That’s a good summary. It seems we have 2 methods that can be used only
> if the CAs using the methods have the design and risk mitigation factors
> reviewed and approved. It’s basically the old “any other method”, except
> before you can use it, the Root programs must review the
> design/implementation and can approve/reject them on a case by case basis.

> Is that where we are with these methods – Not approved unless disclosed and
> reviewed?
>

I think it’s a large leap to go from a potentially
vulnerable/underspecified method to “any other”. It seems you’re ignoring
that .6 and .8 share the same specificity (or lack thereof), or that
GlobalSign is apparently opposed to the removal of .5 and .1, which very
much are insecure in all forms.

I suspect if we are looking to improve security, removing .1 and .5 will go
much further, and much less risk.

> Given this discussion, there must be no other CAs using method 9 or 10,
> else they would have come forward by now with disclosures and have
> demonstrated their compliance.. Maybe we need to post this on the CABF
> public list?
>
>
>
> Based on this, do we need a ballot to remove them from the BRs, or put in
> a statement in them to the effect that they can be used only if approved by
> Google on this list? I’m not picking on Ryan, but he’s the only root
> program representative that has expressed strong views on what is permitted
> and what is not (else you have your CA revoked or root pulled from the
> program).
>

As Wayne has pointed out, CAs participating within the Mozilla program are
expected to be following this list.

That said, in my past messages regarding .9 and .10, I thought it was
rather clear we’d like to see these methods removed if the community is
unable to make progress in securing them, such that the limited exceptions
can be removed and all can use them.

>

[Wayne Thayer]

On Sat, Jan 20, 2018 at 1:07 AM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> <snip>

> > Based on this, do we need a ballot to remove them from the BRs, or put in
> > a statement in them to the effect that they can be used only if approved
> by
> > Google on this list? I’m not picking on Ryan, but he’s the only root
> > program representative that has expressed strong views on what is
> permitted
> > and what is not (else you have your CA revoked or root pulled from the
> > program).
> >
>
> As Wayne has pointed out, CAs participating within the Mozilla program are
> expected to be following this list.
>
> That said, in my past messages regarding .9 and .10, I thought it was
> rather clear we’d like to see these methods removed if the community is
> unable to make progress in securing them, such that the limited exceptions
> can be removed and all can use them.
>

> Mozilla's position is as follows:

Given that the specific vulnerabilities present in BR 3.2.2.4 methods .9
and .10 were reported nearly two weeks ago, Mozilla's minimum expectation
is that all CAs using either method have disclosed that fact and have
described their response on this list. Any CA that has not is now requested
to do so immediately. Currently, Mozilla views new or continued use of
these methods for domain validation to be misissuance unless the CA has
first implemented and disclosed an appropriate mitigation for the known
vulnerabilities. While Mozilla is open to strengthening these methods, CAs
are strongly discouraged from using them and are encouraged to migrate away
from them until such improvements are vetted and standardized by the
CA/Browser Forum.

Note: Please recognize that Mozilla's position applies to our own CA
Program and in no way changes or overrides earlier statements made by Ryan
representing Chrome on this list.

I have added issue #116 to the PKI Policy repository [1] to consider
removing methods 1, 5, 9, and 10 from a future version of the root store
policy.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues

[Mads Egil Henriksveen]

Hi Wayne

Buypass has used the TLS-SNI-01 method in our ACME Pilot running since last summer. We have issued some certificates using this method - less than 60 certificates are still active and not revoked, most of them are issued to internal users and systems.

We stopped using this method immediately when notified by Let's Encrypt on January 10th and we have not used the method since.

Regards
Mads

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+mads.henriksveen=buypa...@lists.mozilla.org] On Behalf Of Wayne Thayer via dev-security-policy
Sent: tirsdag 23. januar 2018 23:12
To: Ryan Sleevi <ry...@sleevi.com>
Cc: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-s...@lists.mozilla.org; Matthew Hardeman <mhar...@gmail.com>; Alex Gaynor <aga...@mozilla.com>
Subject: Re: TLS-SNI-01 and compliance with BRs