Re: Google about to fix the CRL download mechanism in Chrome
Erwann Abalea a écrit : if Google could come up with an efficient mechanism so that revocation is really checked, that's cool. The less than 100k is a challenge, I'd like to see how it will be solved The more since all those random serial numbers can't be compressed. I wonder if he wasn't misinterpreted, and actually meant below 100k *per day*. With the differential sending of information, that's a lot more doable. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
Erwann Abalea a écrit : Who will come with a 12-dan black bar UI? That's a joke on the fact it goes full-cycle at 12-dan and we're back to a white belt, right ? But double-width, so you *can* tell the difference with the normal white bar ;-) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
(Rob asked me to clarify this point.) I would, indeed, like the *total* size of the data to be 100KB. At the moment it's ~70KB with ~1-1.5KB updates every 12 hours. Cheers AGL -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit : [...] A quote from Lucky Green (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html): Most (but not all) of the CAs that I worked with over the years did not have anybody on the operations side full time that would know how to place a revocation reason into the CRL. What kind of CA are these? Which is why the majority of CRL entries include an unspecified reason code or the ever popular reason code NULL. Before Google announce, what was the revocation reason used for? Nothing. One can use it to distinguish certificateHold and removeFromCrl reasons, but its use is seldom. One could eventually perform CRL partitionning, but I've never seen it in practice (and it's not really useful). So even if the revocation reason is taken into account during the revocation action, and stored in the CA database, outputing this reason in a CRL parsed by a machine that doesn't care about why a certificate has been revoked is useless. Now, after some thought (thanks, Jean-Marc), if Google could come up with an efficient mechanism so that revocation is really checked, that's cool. The less than 100k is a challenge, I'd like to see how it will be solved, given the large CA base and unequal technical expertise of them. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
Le mercredi 8 février 2012 21:57:09 UTC+1, Kai Engert a écrit : My criticism: (a) I don't like it that the amount of CRLs will be a subset of all CRLs. What about all the revoked certificates that aren't included in the list? With a dynamic mechanism like OCSP (and in the future OCSP stapling) you don't have to make a selection. OCSPStapling doesn't work. You can have only one OCSP response by the standard, while you need at least 2. It was defined that way in 2006 (RFC4366), and confirmed in 2011 (RFC6066). (b) I don't like it that the CRLs are supposed to be filtered. How can you ensure that no important revocation will be missed? It's the job of CAs to provide good enough CRLs. If they can't do this, can they really be trusted? [...] In my opinion we should rather get our homework done: finally get on-demand downloading of CRLs done (which depends on more helping hands to get the bugs in libPKIX fixed), get OCSP stapling deployed and find a way to require strict revocation checking. The latter will involve creating user interface that allows users to override a temporary OCSP outage, e.g. when using a captive portal in order to get the payment done. That should have been done a long time ago, the revocation checking problem is not new, it only has become more visible with Comodo and DigiNotar events. Mozilla is still the only one to send OCSP requests as POST, bypassing standard cache mechanisms, preventing the use of CDNs to avoid SPOF. I don't share all Google ideas (for example the green bar for DNSSEC certificates), but this one could be promising, let's see. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 10/02/12 21:40 PM, Erwann Abalea wrote: Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit : [...] A quote from Lucky Green (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html): Most (but not all) of the CAs that I worked with over the years did not have anybody on the operations side full time that would know how to place a revocation reason into the CRL. What kind of CA are these? :-) Which is why the majority of CRL entries include an unspecified reason code or the ever popular reason code NULL. Before Google announce, what was the revocation reason used for? Nothing. One can use it to distinguish certificateHold and removeFromCrl reasons, but its use is seldom. One could eventually perform CRL partitionning, but I've never seen it in practice (and it's not really useful). So even if the revocation reason is taken into account during the revocation action, and stored in the CA database, outputing this reason in a CRL parsed by a machine that doesn't care about why a certificate has been revoked is useless. Now, after some thought (thanks, Jean-Marc), if Google could come up with an efficient mechanism so that revocation is really checked, that's cool. The less than 100k is a challenge, I'd like to see how it will be solved, given the large CA base and unequal technical expertise of them. What I surmised was happening was that Google were asking CAs to provide a new CRL for their specifications alone with really must stop these revocations in them. So, any routine compromise or replaced or not-sure or NULL issues aren't to be in there. Which gets it down to numbers less than 1000 for the entire industry -- ones where the CA knows there is trouble. Or, as Alexandre says, 231: http://www.foo.be/cgi-bin/wiki.pl/2011-12-17_Certificate_Revocation_Reasons_2011 That's what I think they are doing. Partitioning at the legal/admin level. I would do something different ;-) So would we all I guess... iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/10/2012 11:40 AM, Erwann Abalea wrote: Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit : [...] A quote from Lucky Green (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html): Most (but not all) of the CAs that I worked with over the years did not have anybody on the operations side full time that would know how to place a revocation reason into the CRL. What kind of CA are these? Last time I tried to ask about specific CAs, I got an answer: You must joking, right? (NDAs are prolific in this line of business.) That's why I favor public disclosure of sub-CA certs that is currently being discusses at mozilla.dev.security.policy. Which is why the majority of CRL entries include an unspecified reason code or the ever popular reason code NULL. Before Google announce, what was the revocation reason used for? Nothing. At the very least it was used by researchers (EFF, crlwatch just to name a few). So even if the revocation reason is taken into account during the revocation action, and stored in the CA database, outputing this reason in a CRL parsed by a machine that doesn't care about why a certificate has been revoked is useless. UI of TLS clients could be different for specific revocation reasons. It's really a corner case (just for the sole purpose of an example). RFC 5280 says: CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries; however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. Why not use it? Following the logic no code I know of parses it anyway we could drop many kinds of fields from other protocols. Now, after some thought (thanks, Jean-Marc), if Google could come up with an efficient mechanism so that revocation is really checked, that's cool. The less than 100k is a challenge, I'd like to see how it will be solved, given the large CA base and unequal technical expertise of them. I'm glad that Google came up with the proposal. Despite being incomplete/controversial, this time the discussion actually may end up in something being changed for the better (instead of the usual oh well ending). Ondrej -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/10/2012 01:26 PM, From ianG: So, any routine compromise or replaced or not-sure or NULL issues aren't to be in there. Which gets it down to numbers less than 1000 for the entire industry -- ones where the CA knows there is trouble. From the point of view of a CA (me) it really doesn't matter - certificates can be either valid, expired or revoked. It's just basic PKI - a revoked certificate is not valid. Certificates can't be a little bit valid, a little bit not valid, just a little bit revoked, not so strongly revoked, slightly revoked or just a little bit longer valid than the expiration date and so forth. Or maybe CAs can start to issue certificates that are slightly valid, sometimes valid and sometimes not, introduce revocation-mild for beginners and for heavy users a super-strong revocation with double belts. Which type of revocation are you? Make your choice -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
Le vendredi 10 février 2012 13:44:20 UTC+1, Ondrej Mikle a écrit : [...] UI of TLS clients could be different for specific revocation reasons. It's really a corner case (just for the sole purpose of an example). Please, not another UI change. We have a green bar that's not displayed the same on all browsers, and sometimes not even a bar. Some proposed a blue bar for OV certs (despite the fact that Chrome and Firefox already display a blue thing for non-EV). Some again proposed other colors for different situations (I read red, yellow, white, etc, depending on the certificate, its validation status, wether there's a mix of TLS/clear objects or not). Who will come with a 12-dan black bar UI? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/10/2012 03:10 PM, Erwann Abalea wrote: Le vendredi 10 février 2012 13:44:20 UTC+1, Ondrej Mikle a écrit : [...] UI of TLS clients could be different for specific revocation reasons. It's really a corner case (just for the sole purpose of an example). Please, not another UI change. I agree with you - the example was purely an abstract example (and was explicitly marked as such). That example was to demonstrate why reason codes in CRL are useful. Ondrej -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
FYI, Adam Langley told me The hope is that everything is 100KB. I asked him if I could share that figure here and he just replied No problem. It's not a strict limit that we set and we'll have to see how well we do. We've calculated that there are currently ~53,000 revoked Server Authentication certs that were issued by Comodo's CA systems, each with a serial number of 16 bytes (+ a leading zero byte if required to ensure it's not treated as a negative number). That adds up to well over 800KB. And obviously we're not the only CA! On 08/02/12 22:18, Nelson B Bolyard wrote: On 2012/02/08 12:57 PDT, Kai Engert wrote: My criticism: [snip] Won't the set of CRLs be too big for download? [snip] This is my question as well. Will they really include the CRLs from all of mozilla's trusted CAs? Won't the union of all those CRLs be huge, even if they strip off certain reason codes? -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 09/02/12 12:54, Rob Stradling wrote: We've calculated that there are currently ~53,000 revoked Server Authentication certs that were issued by Comodo's CA systems, each with a serial number of 16 bytes (+ a leading zero byte if required to ensure it's not treated as a negative number). That adds up to well over 800KB. And obviously we're not the only CA! Which is why he's obviously not going to transmit the information as a list of serial numbers :-) He's probably planning something vaguely like this: http://en.wikipedia.org/wiki/Bloom_filter Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 09/02/12 13:10, Gervase Markham wrote: On 09/02/12 12:54, Rob Stradling wrote: We've calculated that there are currently ~53,000 revoked Server Authentication certs that were issued by Comodo's CA systems, each with a serial number of 16 bytes (+ a leading zero byte if required to ensure it's not treated as a negative number). That adds up to well over 800KB. And obviously we're not the only CA! Which is why he's obviously not going to transmit the information as a list of serial numbers :-) Actually, he is. He's probably planning something vaguely like this: http://en.wikipedia.org/wiki/Bloom_filter I know Adam was looking at Bloom filters and related techniques last year [1], but I understand that he abandoned those approaches. I'm not sure why. The current CRLSet format is described in the Chromium source code [2] (search for CRLSet format). Also, he's published a tool for downloading and parsing CRLSets [3]. [1] http://www.imperialviolet.org/2011/04/29/filters.html [2] http://src.chromium.org/viewvc/chrome/trunk/src/net/base/crl_set.cc?revision=97640view=markup [3] https://github.com/agl/crlset-tools Gerv -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/09/2012 01:20 AM, Brian Smith wrote: I am also concerned about the filtering based on reason codes. Is it realistic to expect that every site that has a key compromise to publicly state that fact? Isn't it pretty likely that after a server's EE certificate has been revoked, that people will tend to be less diligent about protecting the private key and/or asking for the cert to be revoked with a new reason code? You're right, relying on revocation reasons is not a good idea. There are CAs that reportedly don't know how to use them: A quote from Lucky Green (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html): Most (but not all) of the CAs that I worked with over the years did not have anybody on the operations side full time that would know how to place a revocation reason into the CRL. Which is why the majority of CRL entries include an unspecified reason code or the ever popular reason code NULL. Even the CAs that do use revocation reasons in CRLs do not always put them in. For instance, GlobalSign did not state any reason for the certificates revoked due to compromise of their server by the alleged ComodoHacker. Ondrej -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
My criticism: (a) I don't like it that the amount of CRLs will be a subset of all CRLs. What about all the revoked certificates that aren't included in the list? With a dynamic mechanism like OCSP (and in the future OCSP stapling) you don't have to make a selection. (b) I don't like it that the CRLs are supposed to be filtered. How can you ensure that no important revocation will be missed? (c) What about mobile browsers, what about people with expensive mobile data plans, or when roaming? Won't the set of CRLs be too big for download? Even if they use diffs, what about people who use their mobile browser only once or twice a week, and will keep the data connection off during the remainder of the time? Will there be a full set of diffs for the past days still be available to recreate the latest set of signed CRLs, or will browsers end up re-downloading the full set of CRLs on each of those infrequent occassions? But we will have to see numbers in order to judge whether this point is valid criticism. In my opinion we should rather get our homework done: finally get on-demand downloading of CRLs done (which depends on more helping hands to get the bugs in libPKIX fixed), get OCSP stapling deployed and find a way to require strict revocation checking. The latter will involve creating user interface that allows users to override a temporary OCSP outage, e.g. when using a captive portal in order to get the payment done. Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/08/2012 09:58 PM, From Jean-Marc Desperrier: Whereas the optimal solution would be to download each day a delta CRL, with only the difference with the previous day, and containing only the revocation reasons you *really* care about (key compromise). A certificate can be either valid, expired or revoked. A revoked certificate is not valid, no matter the reason (which does not have to be present in the CRL). -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/09/2012 12:18 AM, From Nelson B Bolyard: Will they really include the CRLs from all of mozilla's trusted CAs? Won't the union of all those CRLs be huge, even if they strip off certain reason codes? BTW, this proposal wouldn't be a problem if it would cover, lets say the top 500 sites and leave the rest to the CAs. There would be probably also the highest gains. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
Eddy Nigg wrote: On 02/09/2012 12:18 AM, From Nelson B Bolyard: BTW, this proposal wouldn't be a problem if it would cover, lets say the top 500 sites and leave the rest to the CAs. There would be probably also the highest gains. Effectively, we would be making the most popular servers on the internet faster, and giving them a significant competitive advantage over less popular servers. I am not sure this is compatible with Mozilla's positions on net neutrality and related issues. AFAICT, improving the situation for the top 500 sites (only) would be the argument for *mandatory* OCSP stapling and against implementing Google's mechanism. The 500 biggest sites on the internet all have plenty of resources to figure out how to deploy OCSP stapling. The issue with OCSP stapling is the long tail of websites, that don't have dedicated teams of sysadmins to very carefully change the firewall rules to allow outbound connections from some servers (where previously they did not need to) and/or implement deploy DNS resolvers on their servers (where, previously, they might not have needed any), and/or upgrade and configure their web server to support OCSP stapling (which is a bleeding edge feature and/or not available, depending on the server product). A better (than favor the Alexa 500) solution may be to do auto-load CRLs for the sub-CA that handles EV roots (assuming that CAs that do EV have or could create sub-CAs for EV roots for which there would be very few revocations, which may require standardizing some of the business-level decision making regarding when/why certificates can be revoked), or similar things. This would at least reduce the cost for the long tail of websites to a low* fixed yearly fee. I am not sure this would be completely realistic or sufficient though. I am also concerned about the filtering based on reason codes. Is it realistic to expect that every site that has a key compromise to publicly state that fact? Isn't it pretty likely that after a server's EE certificate has been revoked, that people will tend to be less diligent about protecting the private key and/or asking for the cert to be revoked with a new reason code? However, I don't think we should reject Google's improvement here because it isn't perfect. OCSP fetching is frankly a stupid idea, and AFAICT, we're all doing it mostly because everybody else is doing it and we don't want to look less secure. In the end, for anything serious, we have been relying (and continue to rely) on browser updates to *really* protect users from certificate-related problems. And, often we're making almost arbitrary decisions as to which breaches of which websites are worth issuing a browser update for. Google is just improving on that. Props to Adam, Ben, Wan-Teh, Ryan, and other people involved. Cheers, Brian * Yes, I consider the price of even EV certificates to be almost inconsequential, compared to the overall (opportunity) cost of a person needed to securely set up and maintain even the most basic HTTPS server. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 9/02/12 06:58 AM, Jean-Marc Desperrier wrote: In conclusion I'm 100% in favor of Mozilla adopting this solution, +1 I haven't looked closely but I'm confident they will do the right thing in this area. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/08/2012 04:20 PM, Brian Smith wrote: However, I don't think we should reject Google's improvement here because it isn't perfect. OCSP fetching is frankly a stupid idea, and AFAICT, we're all doing it mostly because everybody else is doing it and we don't want to look less secure. In the end, for anything serious, we have been relying (and continue to rely) on browser updates to*really* protect users from certificate-related problems. And, often we're making almost arbitrary decisions as to which breaches of which websites are worth issuing a browser update for. Google is just improving on that. Props to Adam, Ben, Wan-Teh, Ryan, and other people involved. We do OCSP fetching because CRL fetching on the internet as a whole didn't scale when it was tried. OCSP may not be perfect, but we do it because it's the best thing we have today. OCSP stapling would certainly improve things, which is why it was created, what was it, oh at least 5 years ago. Part of what we are fighting is the general inertia of the web. It took close to 15 years to get OCSP generally turned on! bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 9/02/12 09:18 AM, Nelson B Bolyard wrote: On 2012/02/08 12:57 PDT, Kai Engert wrote: My criticism: [snip] Won't the set of CRLs be too big for download? [snip] This is my question as well. Will they really include the CRLs from all of mozilla's trusted CAs? Won't the union of all those CRLs be huge, even if they strip off certain reason codes? The reason I have confidence in them to make this work, or back off in the event, is that for all Google's many flaws, they are rather good at Internet engineering. This might be considered to be their core competence. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 02/09/2012 02:20 AM, From Brian Smith: Effectively, we would be making the most popular servers on the internet faster, and giving them a significant competitive advantage over less popular servers. I am not sure this is compatible with Mozilla's positions on net neutrality and related issues. Yes certainly it isn't - this is about Google and not Mozilla. And I don't expect Mozilla not to check the status of a certificate either (or at least attempting to check...). AFAICT, improving the situation for the top 500 sites (only) would be the argument for *mandatory* OCSP stapling and against implementing Google's mechanism. Agreed. (I would like to add that we should consider the top 500 secured sites when speaking about those, where essential traffic is generation in SSL mode). The 500 biggest sites on the internet all have plenty of resources to figure out how to deploy OCSP stapling. Absolutely. The issue with OCSP stapling is the long tail of websites, that don't have dedicated teams of sysadmins to very carefully change the firewall rules to allow outbound connections from some servers. I believe stapling will be successful when web servers will do it by default. This is entirely possible and wouldn't require from the admins lots of knowledge. The majority will never turn it on if it's only optional. A better (than favor the Alexa 500) solution may be to do auto-load CRLs for the sub-CA that handles EV roots That's a very good idea (and for the reasons you stated). However, I don't think we should reject Google's improvement here because it isn't perfect. OCSP fetching is frankly a stupid idea, and AFAICT, we're all doing it mostly because everybody else is doing it and we don't want to look less secure. Well, in fact the Mozilla based browsers were one of the first to successfully support OCSP. Most, if not all other browsers either didn't even exist at that time or didn't support OCSP (and CRL checking was not turned on by default either). -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
