Re: Cerificate Concern about Cloudflare's DNS

[Matt Palmer]

On Wed, Nov 02, 2016 at 09:50:41PM -0700, Han Yuwei wrote:
> 在 2016年9月10日星期六 UTC+8下午8:37:40，Han Yuwei写道：
> > I am using Cloudflare's DNS service and I found that Cloudflare has issued 
> > a certficate to their server including my domain. But I didn't use any SSL 
> > service of theirs. Is that ok to Mozilla's policy?
> > 
> > Issued certificate:https://crt.sh/?id=31206531
> > My domain is BUPT.MOE
> 
> Thanks for your time.
> 
> My question remains that,
> 1. If I request Comodo to revoke the certificate, how is it likely to be 
> approved?

Extremely close to zero.

> 2. If Cloudflare use this certificate to perform MITM, how can others know 
> about it?

Cloudflare *do* use their certificates to perform MitM, that's their entire
business model.

> 3. Is this concerned by Mozilla? If it isn't, I wouldn't post anything about 
> it anymore.

I don't speak for Mozilla, but I haven't seen anyone from Mozilla express
concern about the actions of Comodo in this case, and I don't know of any
aspect of Mozilla policies which this behaviour violates.

- Matt

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

Re: Cerificate Concern about Cloudflare's DNS

[Han Yuwei]

在 2016年9月10日星期六 UTC+8下午8:37:40，Han Yuwei写道：
> I am using Cloudflare's DNS service and I found that Cloudflare has issued a 
> certficate to their server including my domain. But I didn't use any SSL 
> service of theirs. Is that ok to Mozilla's policy?
> 
> Issued certificate:https://crt.sh/?id=31206531
> My domain is BUPT.MOE

Thanks for your time.

My question remains that,
1. If I request Comodo to revoke the certificate, how is it likely to be 
approved?

2. If Cloudflare use this certificate to perform MITM, how can others know 
about it?

3. Is this concerned by Mozilla? If it isn't, I wouldn't post anything about it 
anymore.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Matt Palmer]

On Wed, Nov 02, 2016 at 03:44:16PM +0100, Jakob Bohm wrote:
> What is the expected behaviour of a CA when they become aware that
> someone is using illicit/dubious methods to pass an otherwise correct
> application of BR and CPS mandated checks?

The "fraud or misuse" reason for revocation would be triggered, I suspect. 
However, I don't believe that an illicit or dubious method for domain
control validation was used in this case, so it doesn't apply.

- Matt

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

Re: Cerificate Concern about Cloudflare's DNS

[Peter Kurrasch]

It depends. If a CA just hands out a cert to anyone who manipulates DNS, that's 
one thing. If a CA (such as Comodo) has a formal agreement‎ with another party 
(such as CloudFlare) to facilitate the issuance of certs, I think that's quite 
another. The former has all sorts of problems and I'm not so interested in 
rehashing them just now.

The latter, however, has not been formally addressed. I can envision scenarios 
where certs get mis-issued, people blame the CA for having some arrangement 
with CloudFlare (or whomever), and CA's scramble for cover from the storm that 
inevitably follows.‎ I think it would be useful to have some ideas in place in 
advance of any such scenarios. 


  Original Message  
From: Kristian Fiskerstrand
Sent: Wednesday, November 2, 2016 5:41 PM
To: Peter Kurrasch; gerhard.tin...@gmail.com; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Cerificate Concern about Cloudflare's DNS

On 11/02/2016 11:38 PM, Peter Kurrasch wrote:
> This raises an interesting point and I'd be interested in any comments
> ‎that Comodo or other CA's might have.
> 

It really seems like a matter of discussion for the terms of agreement
and interaction between the user and service provider, and not a CA matter.


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Aurum est Potestas
Gold is power

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

Re: Cerificate Concern about Cloudflare's DNS

[Kristian Fiskerstrand]

On 11/02/2016 11:38 PM, Peter Kurrasch wrote:
> This raises an interesting point and I'd be interested in any comments
> ‎that Comodo or other CA's might have.
> 

It really seems like a matter of discussion for the terms of agreement
and interaction between the user and service provider, and not a CA matter.


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Aurum est Potestas
Gold is power



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Peter Kurrasch]

  This raises an interesting point and I'd be interested in any comments ‎that Comodo or other CA's might have.It appears we have a situation where a cert is being issued to what is presumably an authorized party yet that party is not actually authorized by the subscriber. How does Comodo or any other CA validate that a "domain manipulator" has been and continues to be authorized by the actual domain registrant? Is any attestation provided by a party (such as CloudFlare) that they have authorization by their own clients to do whatever they are doing?It's in the interest of CA's to ‎have some well thought-out plans here because I think we know who is getting the blame when the system breaks down. I don't think it would sit well if a CA were to come here and say "you can't blame us for the misissuance because we will give CloudFlare any cert they want."From: gerhard.tin...@gmail.comSent: Wednesday, November 2, 2016 4:16 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Cerificate Concern about Cloudflare's DNSHi, > > Since you delegated your DNS server to Cloudflare, you implicitly allowed them to perform this certificate request on your behalf.> > This is where I strongly disagree! I have checked the TOS and Security policy, ... etc. There is nowhere stated that Cloudflare is allowed without the Users knowledge to manipulate there DNS settings. That sad, there is the proxy service they offer which is changing the DNS settings. But as you actively enable it, you are aware. By delegating the DNS server to Cloudflare, you entrust Cloudflare to distribute the User defined DNS settings. To be able to validate for the certificate, the DNS settings are changed without the users knowledge. No TOS or any other policy states this. Even if that might not be issue for the CA itself (which i do not agree on), This is definitely braking the trust to its users.And the CA (Comodo) informed about it, and not at least requesting a statement from Cloudflare, means they support this, from my point of view, wrong behavior.As it seems the only thing that can be done is move to a different DNS provider!! Still, this is a vialation of trust!!!___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Cerificate Concern about Cloudflare's DNS

[Peter Gutmann]

Tom Ritter  writes:

>There's been (some) mention that even if a user moves off Cloudflare, the CA
>is not obligated to revoke.

Would it matter?  I guess it depends on circumstances (whether you control the
private key or Cloudflare does, whether you intend to use the same domain
elsewhere or not, etc), but in most cases it seems like no revocation is
necessary, you destroy or stop using the private key and that's it.  Even in
the worst-case scenario, Cloudflare has your private key and you intend to
keep using the domain, presumably there's some contractual obligation for them
to stop using it when you close your account with them.  It seems like a
revocation isn't necessary (not just for this but for pretty much every
revocation reason except keyCompromise).

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

Re: Cerificate Concern about Cloudflare's DNS

[Peter Bowen]

On Wed, Nov 2, 2016 at 9:38 AM, Jakob Bohm  wrote:
> On 02/11/2016 17:08, Peter Bowen wrote:
>>
>> On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter  wrote:
>>>
>>> On 2 November 2016 at 09:44, Jakob Bohm  wrote:

 The only thing that might be a CA / BR issue would be this:
>>>
>>>
>>> There's been (some) mention that even if a user moves off Cloudflare,
>>> the CA is not obligated to revoke.  I don't agree with that. If a user
>>> purchased a domain from someone (or bought a recently expired domain)
>>> and a TLS certificate was still valid for it, would the new owner not
>>> be able to get it revoked?  If so, how is this different?
>>
>>
>> Tom,
>>
>> As written today, there is no obligation of CAs to do anything a the
>> request of domain registrants.  There is an obligation that the CA
>> SHALL revoke a certificate if:
>>
>> " The CA is made aware of any circumstance indicating that use of a
>> Fully-Qualified Domain Name or IP
>> address in the Certificate is no longer legally permitted (e.g. a
>> court or arbitrator has revoked a Domain Name
>> Registrant’s right to use the Domain Name, a relevant licensing or
>> services agreement between the Domain
>> Name Registrant and the Applicant has terminated, or the Domain Name
>> Registrant has failed to renew the
>> Domain Name)"
>>
>
> Note that the phrase "services agreement" seems to apply directly to
> the Cloudflare situation.  When a domain owner stops using Cloudflare,
> the services agreement between the domain registrant and Cloudflare has
> terminated.  This when a CA is made aware that a domain registrant has
> stopped using Cloudflare, the above clause is triggered directly,
> leaving only the possibility that the domain registrant explicitly
> wants to keep the certificate in place for an upcoming return to
> Cloudflare.

I agree that would appear to cover this case.

>> Note that this does not give special authority to registrants.  In
>> particular, the straight up "request revocation" option is limited to
>> the _Subscriber_, which is the entity that acquired the certificate.
>>
>> I think that this is a massive gap, especially in the current state of
>> "WebPKI" where certificates are really a third party (CA) assertion
>> that they performed a Trust On First Use (TOFU) operation with the
>> objective that the CA is better positioned avoid attackers than the
>> party later relying upon the certificate.
>>
>>> Aside, it would be very interesting to watch domain renewals + contact
>>> info changes (if one can do this at scale) and pair it up with the CT
>>> logs to see how much of an issue this is/could be.
>>
>>
>> Given that every CA I know of will issue a certificate for a validity
>> period that exceeds the domain registration period, I suspect it is
>> not hard to find many certificates containing FQDNs under expired
>> domains.
>>
>
> Again, the above text explicitly says that if the CA is made aware that
> the domain has not been renewed, it must act accordingly.

Yes, but it does not require CAs to go checking such.  I strongly
doubt any CA is proactively revoking certificates for expired domains.

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

Adding "SecureSign Public CA11" intermediate CA cert to OneCRL

[Kathleen Wilson]

Per Bugzilla Bug #1314464 we are adding the "SecureSign Public CA11" 
intermediate CA cert to OneCRL as a precautionary measure.

Here's some background on this...

The JCSI Root CA (SecureSign RootCA11) was acquired by Cybertrust Japan(CTJ) in 
August 2014.

The current WebTrust CA audit statement for this root is here:
https://cert.webtrust.org/SealFile?seal=2097=pdf

However, there is not a BR audit statement for this root, because CTJ has not 
yet issued their intermediate certificate to sign TLS/SSL certificates. CTJ is 
planning to do this and get a BR readiness audit in March, 2017.

Unfortunately, this "SecureSign Public CA11" intermediate certificate had not 
been transferred to CTJ, even though it chains up to the root certificate that 
CTJ acquired. It is reasonable to assume that JCSI retired this intermediate 
certificate during their liquidation. And data on cert issuance from this 
intermediate certificate seems to back up that assumption. The current 
representatives of CTJ are working to contact the former employees of JCSI to 
confirm this assumption. In the meantime, we are going to add the intermediate 
cert to OneCRL.

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

Re: Cerificate Concern about Cloudflare's DNS

[Gervase Markham]

On 02/11/16 16:01, Nick Lamb wrote:
> Maybe this can to some extent be fixed, but there are many other ways
> in which DNS names now have a footprint that extends beyond the life
> of the domain registration. Cookies and HSTS rules, spam blocks,
> Google search karma, and so on. So arguably buying the domain name
> foo.example "second hand" comes with many risks, pre-existing Web PKI
> certs isn't one of the biggest. 

I think this is probably a reasonable position; I'd say that the domain
name sales market needs to evolve such that their contracts require
sellers to disclose if the domain has ever had SSL certs issued, HSTS
applied, etc. For all I know, that may be true even now.

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

RE: Cerificate Concern about Cloudflare's DNS

[Jeremy Rowley]

Agreed, I'd support a requirement that mandated revocation of a certificate 
using the domain validation processes supported by the CA in issuance. If you 
can prove control enough to get a certificate from the CA, then you are able 
to prove control enough to revoke a certificate.

-Original Message-
From: Tom Ritter [mailto:t...@ritter.vg]
Sent: Wednesday, November 2, 2016 10:45 AM
To: Jeremy Rowley 
Cc: Peter Bowen ; 
mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm 

Subject: Re: Cerificate Concern about Cloudflare's DNS

On 2 November 2016 at 11:24, Jeremy Rowley  wrote:
> Revocation support for non-subscribers is sort of implied...sort of:
>
> Section 4.9.3:
> The CA SHALL provide Subscribers, Relying Parties, Application
> Software Suppliers, and other third parties with clear instructions
> for reporting suspected Private Key Compromise, Certificate misuse, or
> other types of fraud, compromise, misuse, inappropriate conduct, or any 
> other matter related to Certificates. The CA SHALL publicly disclose the 
> instructions through a readily accessible online means.
>

This was the text I was imagining being triggered by this scenario.

I certainly accept the fact that a CA has a reasonable reason to doubt random 
incoming "Please revoke this certificate" requests, and could or should 
require additional verification before taking action. I would imagine that for 
DV revocations, such verification would be pretty much identical to DV 
verification. The hard part is merely automating the process for scale like 
they do for DV issuance. (But if a CA got enough of these requests it could 
save some engineering by reusing that verification infrastructure!)

-tom


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: Cerificate Concern about Cloudflare's DNS

[Tom Ritter]

On 2 November 2016 at 11:24, Jeremy Rowley  wrote:
> Revocation support for non-subscribers is sort of implied...sort of:
>
> Section 4.9.3:
> The CA SHALL provide Subscribers, Relying Parties, Application Software 
> Suppliers, and other third parties with
> clear instructions for reporting suspected Private Key Compromise, 
> Certificate misuse, or other types of fraud,
> compromise, misuse, inappropriate conduct, or any other matter related to 
> Certificates. The CA SHALL publicly
> disclose the instructions through a readily accessible online means.
>

This was the text I was imagining being triggered by this scenario.

I certainly accept the fact that a CA has a reasonable reason to doubt
random incoming "Please revoke this certificate" requests, and could
or should require additional verification before taking action. I
would imagine that for DV revocations, such verification would be
pretty much identical to DV verification. The hard part is merely
automating the process for scale like they do for DV issuance. (But if
a CA got enough of these requests it could save some engineering by
reusing that verification infrastructure!)

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

Re: Cerificate Concern about Cloudflare's DNS

[Jakob Bohm]

On 02/11/2016 17:08, Peter Bowen wrote:

On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter  wrote:

On 2 November 2016 at 09:44, Jakob Bohm  wrote:

The only thing that might be a CA / BR issue would be this:


There's been (some) mention that even if a user moves off Cloudflare,
the CA is not obligated to revoke.  I don't agree with that. If a user
purchased a domain from someone (or bought a recently expired domain)
and a TLS certificate was still valid for it, would the new owner not
be able to get it revoked?  If so, how is this different?


Tom,

As written today, there is no obligation of CAs to do anything a the
request of domain registrants.  There is an obligation that the CA
SHALL revoke a certificate if:

" The CA is made aware of any circumstance indicating that use of a
Fully-Qualified Domain Name or IP
address in the Certificate is no longer legally permitted (e.g. a
court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or
services agreement between the Domain
Name Registrant and the Applicant has terminated, or the Domain Name
Registrant has failed to renew the
Domain Name)"



Note that the phrase "services agreement" seems to apply directly to
the Cloudflare situation.  When a domain owner stops using Cloudflare,
the services agreement between the domain registrant and Cloudflare has
terminated.  This when a CA is made aware that a domain registrant has
stopped using Cloudflare, the above clause is triggered directly,
leaving only the possibility that the domain registrant explicitly
wants to keep the certificate in place for an upcoming return to
Cloudflare.


Note that this does not give special authority to registrants.  In
particular, the straight up "request revocation" option is limited to
the _Subscriber_, which is the entity that acquired the certificate.

I think that this is a massive gap, especially in the current state of
"WebPKI" where certificates are really a third party (CA) assertion
that they performed a Trust On First Use (TOFU) operation with the
objective that the CA is better positioned avoid attackers than the
party later relying upon the certificate.


Aside, it would be very interesting to watch domain renewals + contact
info changes (if one can do this at scale) and pair it up with the CT
logs to see how much of an issue this is/could be.


Given that every CA I know of will issue a certificate for a validity
period that exceeds the domain registration period, I suspect it is
not hard to find many certificates containing FQDNs under expired
domains.



Again, the above text explicitly says that if the CA is made aware that
the domain has not been renewed, it must act accordingly.


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: Remediation Plan for WoSign and StartCom

[Itzhak Daniel]

On Wednesday, November 2, 2016 at 5:22:30 PM UTC+2, Gervase Markham wrote:
> Hi Daniel,
> 
> On 02/11/16 14:11, Itzhak Daniel wrote:
> As far as the DigiCert certs go, it is far too early to have an opinion
> on what Mozilla is or isn't doing.

I have to agree, the time span is too short (at least they didn't backdate).

> I'm not sure what you mean by "ignoring Mozilla Security Community". I
> am happy with the level of communication by Comodo about their incident.

AFAIK they didn't include the TLD '.re' in their incident report [1] (the 
certificate was probably issued on Jun 30th, 2014; Google CT 1st seen 
timestamp: 2014-07-02 14:54:54 GMT [2]), they had the same mistake before the 
'sb' incident, but did/do not acknowledge it officially [3].

Links,
1. 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04274.html
2. https://crt.sh/?id=4467456
3. 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/LQSrnPv2qOo
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Cerificate Concern about Cloudflare's DNS

[Jeremy Rowley]

Revocation support for non-subscribers is sort of implied...sort of:

Section 4.9.3:
The CA SHALL provide Subscribers, Relying Parties, Application Software 
Suppliers, and other third parties with
clear instructions for reporting suspected Private Key Compromise, Certificate 
misuse, or other types of fraud,
compromise, misuse, inappropriate conduct, or any other matter related to 
Certificates. The CA SHALL publicly
disclose the instructions through a readily accessible online means.



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Peter Bowen
Sent: Wednesday, November 2, 2016 10:08 AM
To: Tom Ritter 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm 

Subject: Re: Cerificate Concern about Cloudflare's DNS

On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter  wrote:
> On 2 November 2016 at 09:44, Jakob Bohm  wrote:
>> The only thing that might be a CA / BR issue would be this:
>
> There's been (some) mention that even if a user moves off Cloudflare, 
> the CA is not obligated to revoke.  I don't agree with that. If a user 
> purchased a domain from someone (or bought a recently expired domain) 
> and a TLS certificate was still valid for it, would the new owner not 
> be able to get it revoked?  If so, how is this different?

Tom,

As written today, there is no obligation of CAs to do anything a the request of 
domain registrants.  There is an obligation that the CA SHALL revoke a 
certificate if:

" The CA is made aware of any circumstance indicating that use of a 
Fully-Qualified Domain Name or IP address in the Certificate is no longer 
legally permitted (e.g. a court or arbitrator has revoked a Domain Name 
Registrant’s right to use the Domain Name, a relevant licensing or services 
agreement between the Domain Name Registrant and the Applicant has terminated, 
or the Domain Name Registrant has failed to renew the Domain Name)"

Note that this does not give special authority to registrants.  In particular, 
the straight up "request revocation" option is limited to the _Subscriber_, 
which is the entity that acquired the certificate.

I think that this is a massive gap, especially in the current state of "WebPKI" 
where certificates are really a third party (CA) assertion that they performed 
a Trust On First Use (TOFU) operation with the objective that the CA is better 
positioned avoid attackers than the party later relying upon the certificate.

> Aside, it would be very interesting to watch domain renewals + contact 
> info changes (if one can do this at scale) and pair it up with the CT 
> logs to see how much of an issue this is/could be.

Given that every CA I know of will issue a certificate for a validity period 
that exceeds the domain registration period, I suspect it is not hard to find 
many certificates containing FQDNs under expired domains.

Thanks,
Peter
___
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: Cerificate Concern about Cloudflare's DNS

[Peter Bowen]

On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter  wrote:
> On 2 November 2016 at 09:44, Jakob Bohm  wrote:
>> The only thing that might be a CA / BR issue would be this:
>
> There's been (some) mention that even if a user moves off Cloudflare,
> the CA is not obligated to revoke.  I don't agree with that. If a user
> purchased a domain from someone (or bought a recently expired domain)
> and a TLS certificate was still valid for it, would the new owner not
> be able to get it revoked?  If so, how is this different?

Tom,

As written today, there is no obligation of CAs to do anything a the
request of domain registrants.  There is an obligation that the CA
SHALL revoke a certificate if:

" The CA is made aware of any circumstance indicating that use of a
Fully-Qualified Domain Name or IP
address in the Certificate is no longer legally permitted (e.g. a
court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or
services agreement between the Domain
Name Registrant and the Applicant has terminated, or the Domain Name
Registrant has failed to renew the
Domain Name)"

Note that this does not give special authority to registrants.  In
particular, the straight up "request revocation" option is limited to
the _Subscriber_, which is the entity that acquired the certificate.

I think that this is a massive gap, especially in the current state of
"WebPKI" where certificates are really a third party (CA) assertion
that they performed a Trust On First Use (TOFU) operation with the
objective that the CA is better positioned avoid attackers than the
party later relying upon the certificate.

> Aside, it would be very interesting to watch domain renewals + contact
> info changes (if one can do this at scale) and pair it up with the CT
> logs to see how much of an issue this is/could be.

Given that every CA I know of will issue a certificate for a validity
period that exceeds the domain registration period, I suspect it is
not hard to find many certificates containing FQDNs under expired
domains.

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

Re: Cerificate Concern about Cloudflare's DNS

[Nick Lamb]

On Wednesday, 2 November 2016 15:26:37 UTC, Tom Ritter  wrote:
> There's been (some) mention that even if a user moves off Cloudflare,
> the CA is not obligated to revoke.  I don't agree with that. If a user
> purchased a domain from someone (or bought a recently expired domain)
> and a TLS certificate was still valid for it, would the new owner not
> be able to get it revoked?  If so, how is this different?

ISRG / Let's Encrypt has said that although in principle they are sympathetic 
in this sort of scenario, there would be a big practical obstacle to achieving 
the certainty needed to revoke the old certificate (if they just said "Yes" 
without an investigation then you can DOS any certificate owner by sending off 
emails saying you just bought their domain and need the certificates to be 
revoked...), and they would recommend usually just to wait for the certificate 
to expire naturally (their end entity certificates of course only last 90 days 
each).

That balance might look rather different for a 2 year EV certificate but I 
believe the underlying principle (the validation is OK for a prolonged period 
under the BRs) is the same.

Maybe this can to some extent be fixed, but there are many other ways in which 
DNS names now have a footprint that extends beyond the life of the domain 
registration. Cookies and HSTS rules, spam blocks, Google search karma, and so 
on. So arguably buying the domain name foo.example "second hand" comes with 
many risks, pre-existing Web PKI certs isn't one of the biggest. I suspect that 
even if you could get a license to name a new technology product "Zune" 
tomorrow that would be a bad idea too.

> Aside, it would be very interesting to watch domain renewals + contact
> info changes (if one can do this at scale) and pair it up with the CT
> logs to see how much of an issue this is/could be.

Most large registries go out of their way to make collecting bulk WHOIS data 
(which is what you need here) this technically difficult, largely as a measure 
to protect registrants from truly mind-boggling amounts of spam from SEO 
companies and suchlike.

A legitimate researcher (e.g. someone with related academic credentials) might 
be able to approach them and agree an NDA where they only release aggregate 
statistical results, in exchange for getting the raw data. But it may well just 
not be worth the hassle for a registry to agree that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Tom Ritter]

On 2 November 2016 at 09:44, Jakob Bohm  wrote:
> The only thing that might be a CA / BR issue would be this:

There's been (some) mention that even if a user moves off Cloudflare,
the CA is not obligated to revoke.  I don't agree with that. If a user
purchased a domain from someone (or bought a recently expired domain)
and a TLS certificate was still valid for it, would the new owner not
be able to get it revoked?  If so, how is this different?

Aside, it would be very interesting to watch domain renewals + contact
info changes (if one can do this at scale) and pair it up with the CT
logs to see how much of an issue this is/could be.

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

Hi Daniel,

On 02/11/16 14:11, Itzhak Daniel wrote:
> Interesting that Comodo and DigiCert are getting a different
> treatment, 

As far as the DigiCert certs go, it is far too early to have an opinion
on what Mozilla is or isn't doing. And let us remember, the WoSign
incident involved multiple instances of flat-out lying to Mozilla. I
would expect non-lying CAs to get a different treatment from lying ones.

> I wonder if WoSign/StartCom had ignored Mozilla Security
> Community at some degree, the same way Comodo and DigiCert are doing,
> would it saved them.

I'm not sure what you mean by "ignoring Mozilla Security Community". I
am happy with the level of communication by Comodo about their incident.
DigiCert are still working on theirs. (As are the Government of Spain
and DocuSign.)

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

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

Hi dracenmarx,

On 02/11/16 12:44, dracenm...@googlemail.com wrote:
> (1) I did find any public answer from Apple, Google or Mozilla in
> regards to the Remediation plan by StartCom. I have the feeling, that
> the sanctions were applied without considering this document. (
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf
> ) You didn't even reply to this document after it was mentioned here
> in this discussion.

StartCom were circulating this document to us before it was formally
published. We think their remediation plan is reasonable but it does not
change the decision, which was based on a determination about past
events rather than future promises.

> (2) I am a bit upset about the cuttling line Mozilla set (and which
> was adopted by Chrome yesterday)
> 
> Mozilla announced on October, 24th, that certificates signed on 22
> October or later will be not verified by their future browser
> versions. 

Both StartCom and WoSign were aware in advance that this was the
deadline we were proposing. How they communicated that to their
customers (or not) is up to them. If you are unhappy with them for
selling you a cert which will not meet your requirements, you need to
take it up with them.

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

Re: Remediation Plan for WoSign and StartCom

[Itzhak Daniel]

Interesting that Comodo and DigiCert are getting a different treatment, I 
wonder if WoSign/StartCom had ignored Mozilla Security Community at some 
degree, the same way Comodo and DigiCert are doing, would it saved them.

(I don't know if there are chatters in the back, maybe I missed something and 
these issue are already resolved.)

Comodo Links:
(Their incident report didn't include .re TLD)
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PoMZvss_PRo

DigiCert Links:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/xTKZTDKnNWg
https://bugzilla.mozilla.org/show_bug.cgi?id=1313874
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Jakob Bohm]

On 02/11/2016 15:05, Ryan Sleevi wrote:

On Wednesday, November 2, 2016 at 2:16:34 AM UTC-7, gerhard...@gmail.com wrote:

This is where I strongly disagree! I have checked the TOS and Security policy, 
... etc. There is nowhere stated that Cloudflare is allowed without the Users 
knowledge to manipulate there DNS settings. That sad, there is the proxy 
service they offer which is changing the DNS settings. But as you actively 
enable it, you are aware.


Certainly, this is stated via the CA/Browser Forum's Baseline Requirements, 
which is incorporated in to the Mozilla Policy by reference and which 
enumerates acceptable means to obtain certificates.

You're focused on 'manipulation' of DNS (which is a bit of misnomer), but 
because you're delegating control of the IP to Cloudflare, they can just obtain 
a certificate that way.


And the CA (Comodo) informed about it, and not at least requesting a statement 
from Cloudflare, means they support this, from my point of view, wrong behavior.


As it seems the only thing that can be done is move to a different DNS 
provider!! Still, this is a vialation of trust!!!


If you feel that way, it may suggest Cloudflare may not be the right DNS 
provider for you. As you note, however, it's not an issue for the CA - it's a 
fully permitted and specified method - so if there's issue, this may not be the 
right forum for that.



The only thing that might be a CA / BR issue would be this:

What is the expected behaviour of a CA when they become aware that
someone is using illicit/dubious methods to pass an otherwise correct
application of BR and CPS mandated checks?

As an extreme example, imagine the Hollywood movie scenario where
someone goes into a bank with guns and hoods, and then while they are
in there robbing the cash, they also use their control of the banks
buildings and equipment to obtain an EV certificate that passes all the
usual checks because the Banks CEO had a machine gun at his head when
confirming the request etc. etc.  If the CA learns from the news that
the bank had been completely under siege on those days, should they
revoke the certificate as quickly as possible, or should they wait for
the (now dead) bank CEO to ask for revocation using the account
password he never had?

Note that I am not saying that CloudFlare's actions are illicit or that
the allegations are in any way comparable to armed robbery.  Only that
the CA operational principle in question might be the same.

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: Cerificate Concern about Cloudflare's DNS

[Ryan Sleevi]

On Wednesday, November 2, 2016 at 2:16:34 AM UTC-7, gerhard...@gmail.com wrote:
> This is where I strongly disagree! I have checked the TOS and Security 
> policy, ... etc. There is nowhere stated that Cloudflare is allowed without 
> the Users knowledge to manipulate there DNS settings. That sad, there is the 
> proxy service they offer which is changing the DNS settings. But as you 
> actively enable it, you are aware. 

Certainly, this is stated via the CA/Browser Forum's Baseline Requirements, 
which is incorporated in to the Mozilla Policy by reference and which 
enumerates acceptable means to obtain certificates.

You're focused on 'manipulation' of DNS (which is a bit of misnomer), but 
because you're delegating control of the IP to Cloudflare, they can just obtain 
a certificate that way.

> And the CA (Comodo) informed about it, and not at least requesting a 
> statement from Cloudflare, means they support this, from my point of view, 
> wrong behavior.
> 
> 
> As it seems the only thing that can be done is move to a different DNS 
> provider!! Still, this is a vialation of trust!!!

If you feel that way, it may suggest Cloudflare may not be the right DNS 
provider for you. As you note, however, it's not an issue for the CA - it's a 
fully permitted and specified method - so if there's issue, this may not be the 
right forum for that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[dracenmarx]

I think that the steps against StartCom are too extreme and I would like to 
tell my personal opinion. First of all, I want to say that I don't have any 
benefits when I tell this opinion, since I personally already switched to a 
different CA.

(1) I did find any public answer from Apple, Google or Mozilla in regards to 
the Remediation plan by StartCom. I have the feeling, that the sanctions were 
applied without considering this document. ( 
https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf )
You didn't even reply to this document after it was mentioned here in this 
discussion.

(2) I am a bit upset about the cuttling line Mozilla set (and which was adopted 
by Chrome yesterday)

Mozilla announced on October, 24th, that certificates signed on 22 October or 
later will be not verified by their future browser versions. Are you aware that 
this is really unfair to all customers who have ordered certificates in the 
time frame between 22 and 24 October (without including the time it takes until 
the press spread the news)? They had no chance to base their buying decision on 
the sanction, because the sanction was not published at this time, or published 
by the press / news pages. Correct would have been if Mozilla set the cutting 
line to a future date, after the sanction was announced, for example 1 November.

You, the browser vendors, are not punishing the CAs with this unfortunate 
deadline - you are affecting the webmasters who paid for certificates they 
ordered between 22-24 October, who didn't had any chance to know Mozilla's 
decision.

(3) Since I have read a few variant forms of Mozilla's sanction plan (probably 
some of them were just beta), I have read that it was/is cosidered, that there 
will be a 1 year phase of distrust, before the re-inclusion can happen again. 
Somewhere else I read that the re-inclusion can be July 2017. In any case, 
that's unrealistic and hilarious; If the second largest browser vendor 
(Mozilla) will distrust a CA, then the CA will most likely become bankrupt a 
few months later. I don't think they could survive 1 year. DigiNotar, for 
example, fell into insolvency just a few weeks after they lost the trust by the 
vendors.

(4) I am also a bit upset about Google's decision. They not only also used that 
unfair cutting line date (22 October), but also ruled out every chance in 
rescuing the trust and finding a compromise. I do think every person or company 
should get a second chance. From what I have read and heared, I do think that 
StartCom is now willing to do drastic changes and won't make the same mistakes 
again.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

Hi, 

> 
> Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> them to perform this certificate request on your behalf.
> 
> 
This is where I strongly disagree! I have checked the TOS and Security policy, 
... etc. There is nowhere stated that Cloudflare is allowed without the Users 
knowledge to manipulate there DNS settings. That sad, there is the proxy 
service they offer which is changing the DNS settings. But as you actively 
enable it, you are aware. 

By delegating the DNS server to Cloudflare, you entrust Cloudflare to 
distribute the User defined DNS settings. To be able to validate for the 
certificate, the DNS settings are changed without the users knowledge. No TOS 
or any other policy states this. 

Even if that might not be issue for the CA itself (which i do not agree on), 
This is definitely braking the trust to its users.

And the CA (Comodo) informed about it, and not at least requesting a statement 
from Cloudflare, means they support this, from my point of view, wrong behavior.


As it seems the only thing that can be done is move to a different DNS 
provider!! Still, this is a vialation of trust!!!

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