headers
Gervase Markham | 9 Feb 14:10
Picon
Favicon
Gravatar

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 <at> lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Permalink | Reply | 0 comments |
headers
Gervase Markham | 9 Feb 14:10
Picon
Favicon
Gravatar

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 <at> lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Permalink | Reply | 0 comments |
headers
Gervase Markham | 9 Feb 14:10
Picon
Favicon
Gravatar

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 <at> lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Permalink | Reply | 1 comment |
headers
Eddy Nigg | 9 Feb 01:47
Favicon
Gravatar

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eddy Nigg | 8 Feb 23:45
Favicon
Gravatar

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:    startcom <at> startcom.org
Blog:  	 http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--

-- 
dev-tech-crypto mailing list
dev-tech-crypto <at> lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Permalink | Reply | 3 comments |
headers
Sean Leonard | 8 Feb 23:36
Favicon

Re: Google about to fix the CRL download mechanism in Chrome

Without expressing my opinions on the wisdom of whatever Google is 
proposing...

What Jean-Marc has described (and what the Google post also describes) 
is already covered by RFC 5280 in the concept of "indirect CRL", which 
you can see in Section 5.

It is also worth pointing out that "indirect OCSP" exists in the form of 
"designated OCSP responders". So, you have your online as well as your 
offline options.

The nice thing about indirect CRLs is that they are a standardized 
format. What Mozilla currently does with its internal blacklist, written 
in C++, is basically a highly proprietary form of an indirect CRL. The 
problem (if any) with indirect CRLs is lack of automatic support in the 
crypto stacks: all the more reason to beef up libpkix and the NSS entry 
points to libpkix. Also consider that revocation is cumulative: if you 
have an authoritative list for some reasons (keyCompromise) and a cert 
is not on the list, it doesn't mean that it's valid--just that it's not 
revoked for keyCompromise reasons. You don't need a single CRL (indirect 
or otherwise) for everything; rather, you are supposed to be able to 
compare against multiple lists.

Each valid list you check against reduces the overall risk profile of 
using the certificate. That's the deal. Therefore (in view of Nelson's 
recent comment about size), a list that is very small but lists the 
whole world's keyCompromise certificates, will offer more bang for the 
buck than a huge list from one CA that covers all of the reason codes, 
like affiliationChanged or whatever. You can never drive the risk to 
zero, but you can make it low enough to be pretty acceptable for certain
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eddy Nigg | 8 Feb 22:03
Favicon
Gravatar

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:    startcom <at> startcom.org
Blog:  	 http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--

-- 
dev-tech-crypto mailing list
dev-tech-crypto <at> lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Permalink | Reply | 0 comments |
headers
Kai Engert | 8 Feb 21:57
Picon
Favicon
Gravatar

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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jean-Marc Desperrier | 8 Feb 20:58
Picon
Gravatar

Google about to fix the CRL download mechanism in Chrome

Hi,

Google just published the changes they are about to do in the revocation 
checking in Chrome :
http://www.imperialviolet.org/2012/02/05/crlsets.html

In my opinion, maybe somewhat opposite to the way they describe it, 
fundamentally they are not *at* *all* changing the standard PKI method 
of revocation check.

They are instead just solving a number of flaws in the way the CRL 
revocation information is fetched by browser, therefore implementing a 
new CRL fetching method that *works*, replacing the current *broken* one.

To work properly, CRL fetching must be done in advance of accessing the 
site. This never worked properly when you had to individually, locally 
determine the list of CRL to download.
Therefore establishing  centrally the list of public CRL to download, 
and pushing the result to browsers *is* the proper solution.

The other trouble with CRL in that in practice the only solution that's 
available is to download complete CRL, that include all revocation 
reason, resulting in awful bandwidth requirements.

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

By centrally converting the CRL format to a proprietary optimized format 
that contains only that, they can do it, without implementing in the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kai Engert | 7 Feb 21:58
Picon
Favicon
Gravatar

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

On 07.02.2012 17:54, Ondrej Mikle wrote:
>> The phone calls would ensure that each registered person will be aware
>> of the certificate issuance.
>
> This is getting very close to EV validation (Sovereign Keys have the
> same issue).

I'd say making phone calls is less effort than checking business 
documents, so I'm not convinced it's close to EV - because EV is out of 
reach for anyone running a private server.

> How do you plan on handling CDN services (ones with many certs)?

That's a reason why I propose vouchers to be IP specific.

In my understanding, each IP will have only a single certificate, 
regardless from where in the world you connect to it.

> Another weak point I see is the DNS server for the domain (only
> exception for this seems to be Transparent Certificates and EV
> validation; everything else is susceptible - DANE, Sovereign Keys...).
>
> What about this attack scenario:
>
> 1. attacker compromises DNS server for domain.com or redirects NS record
> 2. now of course he can get DV-validated cert and MitM mails (in
> contrary to the "attacker close to webserver", now it does not matter
> where MX for domain.com pointed to)

EV doesn't help if the attacker simply decides to get a plain DV cert
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kai Engert | 7 Feb 18:04
Picon
Favicon
Gravatar

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

My previous message was a proposed solution to the problem "attacker is 
close to the server and uses it to obtain a new fraudulent cert", and I 
proposed to use an organizational approach to prevent that attack.

In addition, another potential attack is, the attacker has obtained a 
certificate from a "hacked CA", so that no approval process was 
necessary. In addition the attacker is close to the router, so that the 
routes from most (or even all) other CAs can be controlled by the 
attacker, which means the routes from all vouching authorities can be 
controlled by the attacker. With the solution described so far, MECAI 
wouldn't be helpful, because all CAs would happily produce a voucher for 
the attacker.

I hope we can come up with an incremental solution for this attack 
vector on top of the current MECAI proposal.

Here is an initial idea for a solution. It requires that vouching 
authorities keep a record of the recently seen certificates. Whenever a 
server desires to switch to a newer certificate, the server must use TLS 
client authentication with any of the recently seen certificates.

More detailed description:

(Note I mix the terms CA and vouching authority, but both should refer 
to the vouching authority.)

In the beginning, the CA's bookkeeping state for an IP address is empty. 
The first time a CA receives a request for vouching for a new IP address 
with no previous state (or with an expired state), the vouching 
authority will only check the ownership of the certificate (requires
(Continue reading)

Permalink | Reply | 1 comment |

Gmane