Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

On Fri, Jan 19, 2018 at 11:06 AM, Peter Bowen via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Wayne Thayer via dev-security-policy]

On Fri, Jan 19, 2018 at 1:58 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> 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?
>
> Just a reminder that Mozilla policy requires CAs to monitor this list. And
yes I would hope that any other CAs using this method would have disclosed
that fact and their response by now.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Wayne Thayer via dev-security-policy]

Peter,

On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy <
dev-security-policy@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

On Fri, Jan 19, 2018 at 2:58 PM, Doug Beattie 
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 wouldn't necessarily go that far as yet.  The only ones who can speak to
that are the root programs.  The limited guidance available so far suggests
that they won't tolerate perverse consequences to continue even if the
method is BR compliant.  Certainly, there would be no shortage of
supporters for removal of the #9 and #10 methods as written.



>
>
> 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?
>

One would think there must be no others.  In the alternative, someone is
dilatory.


>
>
> 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).
>
>
>

Therein is the real question.  If we go with the assumption that the
vulnerable methods are in fact BR compliant, someone should probably fix
the BRs.  More urgently, perhaps the root programs should all issue
guidance on acceptability of these methods or mitigations over the
methods.  The obvious safe leap of logic to make is to assume in the most
securely constrained light: that all the root programs reject the mechanism
underlying a method which has significant demonstrable holes when applied
in the real world.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Taiwan GRCA Root Renewal Request

[Wayne Thayer via dev-security-policy]

This root inclusion request is currently in the public discussion phase [1]

After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the 
following comments:

==Good==
1. GRCA has requested that this root be constrained to issuing certificates for 
.tw domains.
2. The BR Self Assessment is very detailed and helpful.

==Meh==
1. This root is intended to replace an older root that has the exact same DN. 
Compatibility concerns were raised but testing performed by GRCA found no 
problems.
2. The CP doesn’t contain the ’dated changelog’ required under Mozilla policy 
section 3.3.
3. The audit reports don’t include the version numbers of CA policy documents 
referenced during the audit.
4. The WebTrust for CAs audit report doesn’t list all the subordinate CAs 
covered by the audit. They are listed in a supplemental statement provided by 
the auditor.
5. The CP/CPS docs are still in RFC 2527 format.
6. It is not clear how the policy for authenticating individual identity 
described in section 3.1.9 of the GCA CPS meets the requirements of BR 3.2.3 
and 3.2.5. Please provide more detail.
7. In September it was reported that GRCA was signing OCSP responses with an 
unconstrained SHA-1 certificate: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 The issue has been fixed.
8. Procedures that fulfill Mozilla policy section 2.2(2) requirements for 
validating email addresses are not specified in any documents.

==Bad==
1. The application for inclusion states that only the GCA subordinate can issue 
SSL certificates, and this subordinate has its own CPS that lists SSL-specific 
policies such as CAA. The HCA subordinate also has a BR audit, but GRCA has 
stated that it is no longer used to issue SSL certificates. Should the HCA 
subordinate be added to OneCRL along with the other subordinates (XCA, MOICA, 
and MOECACA) that are not BR audited?
2. According to the audit supplement, the MOICA audit report is qualified due 
to ‘one issue related to system access management’, but the actual audit report 
is not written in English. Please describe the issue and how it was resolved.
3. The GCA CPS describes CAA policies, but GRCA’s issuer domain names are not 
listed as required by BR section 2.2.
4. GCA CPS section 3.1.12 describes the domain authorization process for SSL 
certificates, but it does not comply with Mozilla policy section 2.2(3).

One of the recent updates to the application process [1] is a 3-week time 
period for public comments. I would like to apply that change to this inclusion 
request. Specifically, if GRCA has sufficiently answered the questions that I 
have raised above, and any other discussion on this list has reached a 
conclusion, then I will plan to close the discussion period on 10-Feb.

- Wayne

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1065896
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: TLS-SNI-01 and compliance with BRs

[Doug Beattie via dev-security-policy]

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:mharde...@gmail.com]
Sent: Friday, January 19, 2018 1:45 PM
To: Doug Beattie 
Cc: r...@sleevi.com; Alex Gaynor ; 
mozilla-dev-security-pol...@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.

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 19, 2018 at 1:44 PM, Matthew Hardeman 
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)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

On Fri, Jan 19, 2018 at 9:22 AM, Doug Beattie via dev-security-policy <
dev-security-policy@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 

Re: TLS-SNI-01 and compliance with BRs

[Jakob Bohm via dev-security-policy]

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/ 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 hostmaster@zoneapex.example.

For e-mail certificates (no current BR rules, only root program specific
rules), ability to receive emails for exam...@example.com validates (at
class 1 level) control of that one e-mail address.  While control of
postmas...@example.com or hostmas...@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 postmas...@hotmail.com can't get certificates
for all the users without directly violating the sanctity of the e-mail
accounts).


On 19/01/2018 16:22, Doug Beattie 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.


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:r...@sleevi.com]
Sent: Thursday, January 18, 2018 7:25 PM
To: Doug Beattie 
Cc: Alex Gaynor ; 
mozilla-dev-security-pol...@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 

Re: TLS-SNI-01 and compliance with BRs

[Peter Bowen via dev-security-policy]

> On Jan 19, 2018, at 7:22 AM, Doug Beattie via dev-security-policy 
>  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 19, 2018 at 10:22 AM, Doug Beattie 
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:r...@sleevi.com]
> *Sent:* Thursday, January 18, 2018 7:25 PM
> *To:* Doug Beattie 
> *Cc:* Alex Gaynor ; mozilla-dev-security-policy@
> 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 

RE: TLS-SNI-01 and compliance with BRs

[Doug Beattie via dev-security-policy]

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:r...@sleevi.com]
Sent: Thursday, January 18, 2018 7:25 PM
To: Doug Beattie 
Cc: Alex Gaynor ; 
mozilla-dev-security-pol...@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 
>
 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 

RE: TLS-SNI-01 and compliance with BRs

[Tim Hollebeek via dev-security-policy]

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=digicert@lists.mozilla.org] On Behalf Of J.C.
Jones
> via dev-security-policy
> Sent: Thursday, January 18, 2018 3:34 PM
> To: Matthew Hardeman 
> Cc: Doug Beattie ; mozilla-dev-security-
> pol...@lists.mozilla.org; Alex Gaynor 
> Subject: Re: TLS-SNI-01 and compliance with BRs
> 
> 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
> 
> wrote:
> 
> >
> >
> > On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy <
> > dev-security-policy@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.
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria (organizations)

[Jakob Bohm via dev-security-policy]

On 19/01/2018 11:09, Gervase Markham wrote:

On 19/01/18 01:05, Jakob Bohm wrote:

On 18/01/2018 11:01, Gervase Markham wrote:

On 17/01/18 19:49, Jakob Bohm wrote:

3. Major vertical CAs for high value business categories that issue
    publicly trusted certificates at better than EV level integrity.  For


How do you define "major"? And "high value business category"?


Major would be the biggest 1 to 3 of their kind, ignoring any covering
only a small fraction of the relevant web site/e-mail population even if
in the top 3.  Also any not doing this globally is not major.


I guess my question was ambiguous. Clearly it's very easy to come up
with arbitrary definitions for these things, but what's the rationale?
Why 1-3? Why not 1-8?



My suggestions are only meant to inspire formal rules written / chosen
by module leaders such as you.

Point of this is to avoid a bloated situation with 50+ financial
industry specific CAs and 50+ medical profession CAs etc.  This would
generally be for single worldwide organizations, with an option to
handle some kind of alliance schism in the industry, e.g. between those
who align with EuroCard/Visa/Mastercard (EVM) and another global group
that explicitly wants as little to do with the first group as possible.


High value business category would be a category where web users have an
extremely high need for genuineness.  Banks/central payment systems
would be the canonical example, with the VISA CA/SET combination as a
possible historic example (noting that it looks like they don't
currently qualify even if they did in the past).


You've just shifted the definitional problem to the words "extremely
high need for genuineness".

Proving examples of what you personally mean by these terms is not
sufficient to make a definition, unless the Mozilla policy becomes
"whatever Jakob Bohm decides".

Gerv




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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria (organizations)

[Gervase Markham via dev-security-policy]

On 19/01/18 01:05, Jakob Bohm wrote:
> On 18/01/2018 11:01, Gervase Markham wrote:
>> On 17/01/18 19:49, Jakob Bohm wrote:
>>> 3. Major vertical CAs for high value business categories that issue
>>>    publicly trusted certificates at better than EV level integrity.  For
>>
>> How do you define "major"? And "high value business category"?
> 
> Major would be the biggest 1 to 3 of their kind, ignoring any covering
> only a small fraction of the relevant web site/e-mail population even if
> in the top 3.  Also any not doing this globally is not major.

I guess my question was ambiguous. Clearly it's very easy to come up
with arbitrary definitions for these things, but what's the rationale?
Why 1-3? Why not 1-8?

> High value business category would be a category where web users have an
> extremely high need for genuineness.  Banks/central payment systems
> would be the canonical example, with the VISA CA/SET combination as a
> possible historic example (noting that it looks like they don't
> currently qualify even if they did in the past).

You've just shifted the definitional problem to the words "extremely
high need for genuineness".

Proving examples of what you personally mean by these terms is not
sufficient to make a definition, unless the Mozilla policy becomes
"whatever Jakob Bohm decides".

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 18/01/18 14:24, Ryan Sleevi wrote:
> Or, conversely, that we cannot discuss inclusion policies in isolation from
> discussion root policies - we cannot simultaneously work to strengthen
> inclusion without acknowledging the elephant in the room of the extant CAs.

We aren't necessarily "strengthening" inclusion, in the sense of making
it harder to get in - the outcome of the discussion could be a loosening.

If we come up with new inclusion criteria and some existing CAs do not
meet them, we would need to have a separate discussion to decide what to
do, with the main options being grandfathering them in, restricting them
in some way, or removing them.

> Isn't this effectively the VISA situation? When were their first audits -
> late 2016 / early 2017?

I'm not certain; I'll ask Kathleen.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy