Re: SHA-1 issuances in 2016 That Chain to Mozilla Roots
On Saturday, 5 November 2016 15:56:39 UTC, Peter Bowen wrote: > Is this a problem? Maybe. We know about the risks of pivoting, but if > browsers disable SHA-1 that risk goes away. The risk exists so long as anything trusts SHA-1 signatures. Disabling SHA-1 in current versions of browsers narrows the scope of the risk, and we hope that doing so alters the value proposition of an attack, thereby also protecting the rest of the ecosystem -- but the risk doesn't vanish altogether. If it gets cheap enough - and CAs contribute to that by routinely signing things an attacker could interfere with - even a very modest pay-off would be worthwhile. If creating a collision becomes cheap enough it could be viable even for spear-phishing a single target. Big Boss has a crappy phone that isn't getting security updates any more? MITM their Internet connection and interpose a certificate produced through SHA-1 collision to impersonate their bank, spin a convincing story, get their credentials, empty their accounts. As far as the target knows it's an inside job by the bank, could take months before anybody would understand what really happened. The browser change is defence in depth, the CAs have a big role to play here in eliminating SHA-1 signing and taking steps to make exploiting it harder and less useful, such as the use of EKUs on intermediates and forcing certificates to have long, unpredictable serial numbers to make chosen prefix attacks harder. ___ 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
On Sunday, November 6, 2016 at 12:11:43 AM UTC+2, Ryan Sleevi wrote: > Can you tell me where that clause indicates that they should use the Alexa > Top 1 million to consider a request "High Risk"? It doesn't, "High risk" is left for the CA's interpretation. But after the fact you can say that they failed to identify a "High risk" request with their current state of their system and they SHOULD be required to update it (to avoid future requests to pass for the specific domain in question), and they MAY need to make their system more robust to identify other "High risk" requests and not just acting after the fact. Alexa top ~1000 is a good indicator for requests that should be considered as "High risk" [1] [2], especially in a free tier service. Links: 1. https://github.com/certbot/certbot/issues/47#issuecomment-64060616 2. https://community.letsencrypt.org/t/name-is-blacklisted-on-renew/9012/19 ___ 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
On Saturday, November 5, 2016 at 2:54:05 PM UTC-7, Itzhak Daniel wrote: > (to my understanding) They did violate a "SHALL" guideline: > > "The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity for High Risk > Certificate > Requests prior to the Certificate’s approval, as reasonably necessary to > ensure > that such requests are properly verified under these Requirements." > > I don't recall if they automatically approved or manually approved it by > mistake (the operator wasn't familiar with Alibaba). > > alicdn.com is ranked 760 in Alexa top 1 million, and requests for this domain > should be considered "high risk": > > CMD$ wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip;gzip -cd > top-1m.csv.zip|grep alicdn.com Can you tell me where that clause indicates that they should use the Alexa Top 1 million to consider a request "High Risk"? This is a known, and well understood, issue with the clause - it is perfectly acceptable from the BRs, and therefore, at present, the Mozilla policy, to state that "We consider any requests for the domain example.com as 'High Risk', and all other domains shall not be considered as such" What's required is they have a policy, and document the policy, and follow the policy. That's it. Is that ideal? No. But is that what it says? Absolutely. CAs and Browsers have been discussing this nuance for several years now, but certainly, at the time it happened, and to this present day, it means the above. ___ 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
On Friday, November 4, 2016 at 12:18:40 PM UTC+2, Gervase Markham wrote: > ... But because WoSign had done the appropriate domain control checks, > we did not consider this a mistake by WoSign. (to my understanding) They did violate a "SHALL" guideline: "The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements." I don't recall if they automatically approved or manually approved it by mistake (the operator wasn't familiar with Alibaba). alicdn.com is ranked 760 in Alexa top 1 million, and requests for this domain should be considered "high risk": CMD$ wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip;gzip -cd top-1m.csv.zip|grep alicdn.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla CT Policy
On Friday, November 4, 2016 at 5:32:23 AM UTC-7, Hanno Böck wrote: > Hi, > > Great to see Mozilla committing to CT. > > On Fri, 4 Nov 2016 12:19:32 + > Gervase Markham wrote: > > > So, please add comments with additional _questions_ you think the > > policy will need to address. What the answers should be is (for now) > > off-topic. > > Some meta-thought: > In practice pretty much every webpage wants to be compliant with all > major browsers. It's hard to imagine anyone saying "I'll comply with > Chrome's CT requirements, but not with Mozilla's" (or vice versa). > > Therefore practically the "real" CT requirements will be all > requirements combined. It also probably means that diverity in CT > requirements between different browsers doesn't make a whole lot of > sense. > > So one could ask: Should mozilla just say "we agree with everything > Chrome does" ? This is a very useful point to consider. As has been repeatedly stated in Chrome's discussion of CT, the requirement for one Google/one non-Google is due to the absence of SCT->STH verification, and the absence of Gossip, in current versions of Chrome (it's being worked on). In the absence of this, if you trust an SCT from a log, you're effectively trusting that log to be honest - there's no validation occurring that the log isn't providing a split view (perhaps to users inside a particular network block/country and those outside) My understanding was that Mozilla's implementation status was similar to Chrome's a year ago - that is, that it doesn't implement inclusion proof fetching (in the background) and that work hadn't been scheduled/slated yet. In that case, it's a question for Mozilla about whether to trust that logs won't lie, or whether to verify. In Google's case, the one-Google/one-non-Google was merely an interim stopgap towards that solution - because it resolves the "I don't trust other logs" aspect by trusting Google logs (which, at least for Chrome's threat model, is no different than trusting Google not to deliver hostile updates to Chrome users), while giving others the relief that they don't have to solely/entirely trust Google (by having a third-party expression). So I think the question about 'CT Qualification' (to steal Chrome's term) is at least useful to consider that point, about threat models - which, admittedly, I haven't been very good at articulating on Chrome's ct-policy@ all the ways in which we expect/planned for things to go wrong, and attempted to design against that, as well as all the things we knew we didn't know solutions for, in which case, we tried to leave things open. I'll hopefully have more news in the following weeks, on Chrome's ct-policy list, but I think we're interested in hosting another "CT days" event, this time in the US, similar to the events we held in conjunction with the ETSI CA days in Europe. This would hopefully provide for an opportunity of a real time roundtable and discussion of these sorts of issues, across browsers, log operators, and relying parties, to better explore how we can develop both an immediate and long-term healthy ecosystem. Think of it as the "CT/Log Roundtable", and we'll try to figure out solutions for remote participation as well. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla CT Policy
On Saturday, November 5, 2016 at 10:59:04 AM UTC-7, Tom Ritter wrote: > > * Are there any CT-related services Mozilla should consider running or > > supporting, for the good of the ecosystem? > > Part answer, part question, but I don't want to forget it: Besides an > Auditor, perhaps Mozilla should run a DNS log query front-end to > provide diversity from Google's. > > -tom For specificity sake: Tom's talking about having Mozilla operate a set of DNS endpoints that implement https://github.com/google/certificate-transparency/blob/master/docs/DnsServer.md To implement that, it effectively requires running a set of CT mirrors, so that you can provide the merkle tree inclusion proofs for arbitrary SCTs and STHs. If not that, then it's worth Mozilla noodling how it wants to check SCTs' inclusion in a privacy preserving fashion. It may very well be that Mozilla feels that DNS doesn't afford that privacy. However, it would be super useful to know that and for implementors - Mozilla, Apple, others - to help collaboratively figure out solutions rather than inventing new ones ad-hoc :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla CT Policy
On 4 November 2016 at 07:19, Gervase Markham wrote: > * Are there any CT-related services Mozilla should consider running or > supporting, for the good of the ecosystem? Part answer, part question, but I don't want to forget it: Besides an Auditor, perhaps Mozilla should run a DNS log query front-end to provide diversity from Google's. -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 issuances in 2016 That Chain to Mozilla Roots
> On Nov 5, 2016, at 6:49 AM, Ryan Sleevi wrote: > > On Saturday, November 5, 2016 at 2:06:00 AM UTC-7, Gervase Markham wrote: >> On 04/11/16 21:23, Ryan Sleevi wrote: >>> If there's concerns about GAs - would it be best to reply on this thread or >>> start a new one per-CA? >> >> If there's more than one CA, perhaps a new one per CA would be better, >> please. > > Well, mostly I'm trying to understand why you listed the following as "GA - > EKU but not serverAuth" > https://crt.sh/?cablint=211&iCAID=70&minNotBefore=2016-01-01&opt=cablint > https://crt.sh/?cablint=211&iCAID=104&minNotBefore=2016-01-01&opt=cablint > > Even though the individual certs, such as > https://crt.sh/?id=39635446&opt=cablint or > https://crt.sh/?id=31394742&opt=cablint , have an EKU, their issuing CAs, > https://crt.sh/?caid=104&opt=cablint and https://crt.sh/?caid=70&opt=cablint > , do not. > > As noted elsewhere, the issuance of SHA-1 allows for an attacker to pivot the > contents of the certificates, and the only mitigation is the EKU on the > sub-CA. > > Are you suggesting this is GA because it wasn't clear enough to CA members at > the time this was issued? Because I can't help but feel that this particular > point was discussed at considerable length prior to these CA's issuances. There is no policy from any trust store, as far as I know, that says the private key for a CA cannot be used to create signatures over SHA-1 hashes. The policies are all about the content that goes into the hash and, as far as I know, only limit the content if the content is a certificate usable for server authentication. Is this a problem? Maybe. We know about the risks of pivoting, but if browsers disable SHA-1 that risk goes away. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 issuances in 2016 That Chain to Mozilla Roots
On Saturday, November 5, 2016 at 2:06:00 AM UTC-7, Gervase Markham wrote: > On 04/11/16 21:23, Ryan Sleevi wrote: > > If there's concerns about GAs - would it be best to reply on this thread or > > start a new one per-CA? > > If there's more than one CA, perhaps a new one per CA would be better, > please. Well, mostly I'm trying to understand why you listed the following as "GA - EKU but not serverAuth" https://crt.sh/?cablint=211&iCAID=70&minNotBefore=2016-01-01&opt=cablint https://crt.sh/?cablint=211&iCAID=104&minNotBefore=2016-01-01&opt=cablint Even though the individual certs, such as https://crt.sh/?id=39635446&opt=cablint or https://crt.sh/?id=31394742&opt=cablint , have an EKU, their issuing CAs, https://crt.sh/?caid=104&opt=cablint and https://crt.sh/?caid=70&opt=cablint , do not. As noted elsewhere, the issuance of SHA-1 allows for an attacker to pivot the contents of the certificates, and the only mitigation is the EKU on the sub-CA. Are you suggesting this is GA because it wasn't clear enough to CA members at the time this was issued? Because I can't help but feel that this particular point was discussed at considerable length prior to these CA's issuances. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
This looks like a very accurate representation of the data protection European
regulations. I have the same view.
Not so easy to implement but if it is implemented correctly, I think very few
people will disagree with the essence of this regulation.
Dimitris.
--
Sent from my mobile device. Pls excuse brevity and typos
> On 5 Nov 2016, at 11:50, Nick Lamb wrote:
>
>> On Friday, 4 November 2016 19:37:07 UTC, Jeremy Rowley wrote:
>> We also like the public disclosures CT requires as its been essential in
>> identifying issuing CAs and non-compliances. That's probably not a surprise
>> as we've always strongly supported CT. I do see the need for name redaction
>> though as lots of the certificates are issued to individuals, and the
>> European government freaks out whenever there is the potential disclosure of
>> PII.
>
> Unlike with DNS names / IP addresses in the Web PKI, I could still be
> persuaded that redacting personal information about individual human
> subscribers would make sense.
>
> Nevertheless I think it's valuable to understand that European regulations in
> this area ("Data Protection" is the usual English term) are not intended to
> altogether prohibit the disclosure of PII. The regulations are instead
> focused on ensuring that subjects know what is held about them, that they're
> told how it will be used and why, that the data used is adequate yet not
> excessive for that purpose, and that they can get any mistakes fixed.
>
> So Data Protection could permit unredacted CT logging if it served some
> legitimate purpose, particularly one that's in the subject's best interest
> such as deterring identity fraud or protecting the integrity of the
> certificate ecosystem they're using, and if subscribers were told about this
> before they request the certificate.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://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: Update on transition of the Verizon roots and issuance of SHA1 certificates
On Friday, 4 November 2016 19:37:07 UTC, Jeremy Rowley wrote:
> We also like the public disclosures CT requires as its been essential in
> identifying issuing CAs and non-compliances. That's probably not a surprise
> as we've always strongly supported CT. I do see the need for name redaction
> though as lots of the certificates are issued to individuals, and the
> European government freaks out whenever there is the potential disclosure of
> PII.
Unlike with DNS names / IP addresses in the Web PKI, I could still be persuaded
that redacting personal information about individual human subscribers would
make sense.
Nevertheless I think it's valuable to understand that European regulations in
this area ("Data Protection" is the usual English term) are not intended to
altogether prohibit the disclosure of PII. The regulations are instead focused
on ensuring that subjects know what is held about them, that they're told how
it will be used and why, that the data used is adequate yet not excessive for
that purpose, and that they can get any mistakes fixed.
So Data Protection could permit unredacted CT logging if it served some
legitimate purpose, particularly one that's in the subject's best interest such
as deterring identity fraud or protecting the integrity of the certificate
ecosystem they're using, and if subscribers were told about this before they
request the certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On Sat, Nov 05, 2016 at 09:09:49AM +, Gervase Markham wrote: > > If they had sent an incident report to Mozilla I would agree, but I do > > not think that CAs should be credited for noticing mistakes when they > > try to sweep them under the rug. This is particularly true in the case > > of SHA-1 misissuance, where revoking without broader notification > > demonstrates not competence but rather a lack of understanding of the > > risks. > > Your point being that if they do disclose, the community can then run > crypto analysis over the cert to see if it's likely to be constructed as > part of a collision attempt? I think in general we want to hear from CAs about any incident, including BR violations. For all the bugs we filed in bugzilla about SHA-1, 1024 bit RSA keys, and so on there should be an incident report, and it should _at least_ be mentioned in their audit. But they really should send such incident reports to all root programs at the moment they knew about it. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 04/11/16 23:51, Andrew Ayer wrote: > The March 2016 CA communication said[1]: > > "It has been pointed out in the mozilla.dev.security.policy forum that > a chosen-prefix attack on SHA-1 could be used to forge a certificate if > a CA's private key is used to sign *anything* with SHA-1." > > Therefore, CAs participating in the Mozilla program know that this > practice is dangerous. This is true; however, unfortunately, I don't believe this amounts to a requirement that CAs should not use SHA-1 at all any more. > Frankly, I'm disappointed that despite my efforts to draw attention to > this issue in March, both in the context of non-serverAuth certificates[2] > and OCSP responses[3], Mozilla took no further action, such as > amending Mozilla policy or proposing a CABF ballot to plug this hole. Your disappointment stings. > If they had sent an incident report to Mozilla I would agree, but I do > not think that CAs should be credited for noticing mistakes when they > try to sweep them under the rug. This is particularly true in the case > of SHA-1 misissuance, where revoking without broader notification > demonstrates not competence but rather a lack of understanding of the > risks. Your point being that if they do disclose, the community can then run crypto analysis over the cert to see if it's likely to be constructed as part of a collision attempt? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 issuances in 2016 That Chain to Mozilla Roots
On 04/11/16 21:23, Ryan Sleevi wrote: > If there's concerns about GAs - would it be best to reply on this thread or > start a new one per-CA? If there's more than one CA, perhaps a new one per CA would be better, please. Note that marking an issuance as "GA" doesn't mean it might not be added if later we are assembling an "issues list" for a CA who we think has reached some threshold of regularly-demonstrated incompetence or malice. Even if I don't pursue a CA about a particular BR violation (SHA-1 or otherwise), I would expect them to have done an internal investigation and be ready to explain what happened at some later point, if asked. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla CT Policy
Hey list, Here are some suggestions: Should we define log algorithm/key requirements (hashing algorithms (relevant with RFC6962-bis), asymmetric key type and length)? Should we define a maximum threshold on log response delay to queries? (e.g. is it acceptable for a log to answer to queries with a delay of tens of seconds or even minutes?) Should we authorize log trust anchor list variations? If so, should variations have to be publicly disclosed? Should we authorize removal of trust anchors? Should a log be authorized to reject add-chain calls when under stress? Should we limit how often this happens? Should we want to restrict the protocol version and cipher suites that are supported by the log HTTPs endpoints? Cheers, Florian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
