[cabfpub] Preballot for IPv6 Support

Thu Feb 5 16:34:25 UTC 2015

Ryan,

GlobalSign, both GlobalSign proper and our CDN provider, support IPv4 and IPv6 for OCSP and CRLs today.

Doug

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, December 17, 2014 12:50 AM
To: Jeremy Rowley
Cc: CABFPub
Subject: Re: [cabfpub] Preballot for IPv6 Support

For the sake of the Forum and those questioning the value of this, I'd like to point out that this is not just theoretical for clients.

Consider this message  -http://seclists.org/nanog/2014/Dec/114 - to NANOG from one of the largest USP ISPs, Time Warner Cable about the trouble that they're having making a client that "Does PKI right" and the challenges they face (Robert's bio from the ARIN Advisory Council to fill in the value for $DAYJOB - https://www.arin.net/about_us/ac.html#rseastrom )

The lack of IPv6 universally penalizes a client that chooses to support revocation checking, because now in addition to supporting IPv6 on the server, server operators have to be aware of their CA's infrastructure support for IPv6.

What's worse, if you look at the incentives, this penalizes the client. From the user's perspective, the choice to implement revocation checking is the fault of the device manufacturer/deployer (Time Warner), rather than an issue with the remote server. The remote server is unlikely to be told by end users that their site doesn't work when using Time Warner devices - instead, Time Warner will be told that the server doesn't work with them. These sorts of penalties have already been reported by browsers that have lead to questioning the revocation strategies, but this is yet another ecosystem affected.

On Tue, Dec 16, 2014 at 8:29 PM, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
The proposal is more likely to force CAs into using their own infrastructure to provide revocation information than forcing CDNs and hosting providers to use IPv6, slowing OCSP response times. However, nothing wrong with gathering the information and looking at which CDNs and providers we need to get on board with the proposal.

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>] On Behalf Of Ryan Sleevi
Sent: Monday, December 15, 2014 2:59 PM
To: Eddy Nigg
Cc: CABFPub
Subject: Re: [cabfpub] Preballot for IPv6 Support

On Mon, Dec 15, 2014 at 1:16 PM, Eddy Nigg <eddy_nigg at startcom.org<mailto:eddy_nigg at startcom.org>> wrote:

On 12/15/2014 11:02 PM, Ryan Sleevi wrote:
As discussed on our call last week, I'd like to put together a ballot requiring that CAs support IPv6 for their external (relying party facing) infrastructure.

Funny that you want to start with that part first - most of the time that's the part CAs have the least control over it and depend on third parties.

I'm not sure I follow this. CAs aren't required to delegate their infrastructure out to third-parties. If they chose to, then they have to pick third-parties who are capable of meeting the Baseline Requirements (e.g. the current 24/7 uptime requirements or the 10 second availability).

If a new requirement comes down, the question is how long will it take for the CAs to either get their infrastructure updated, get their third parties to update, or transition to new third parties. That's fundamentally the question I'm asking. This is surely NOT a problem that's impossible. If CAs are telling third parties that they need IPv6 support, then eventually there will be IPv6 support.

As both servers and clients transition to IPv6-only networks, the goal is to ensure that services RPs need are accessible.

Hardly 5 % as of today - and I assume they all (must) support IPv4 in any case since the vast majority doesn't support IPv6.

That's an assumption that is, in part, caused by the unavailability of some services over IPv4. This is a collective action problem, as the CA industry is quite familiar with, so I don't understand why "we don't support it today" is necessarily an argument for why "we shouldn't support it tomorrow".

Before proposing dates/timelines, it'd be helpful to understand where the CA's current infrastructure and plans are, so that we can reach a happy medium.

I believe this is premature by any standard. Of course CAs may and probably want to support IPv6 as soon as there is a real demand for it. It's also not overly difficult - but the real problem is the third party service providers involved including CDNs and ISPs which must provide IPv6 support first before the CA can.

I fail to see how this is premature. It's exactly the same conversation that had to happen with SHA-1 - CAs weren't moving to support it, so eventually timelines had to be set. This is a classic collective action problem, and it's simply a question of what is a reasonable timeframe for CAs to move, and why.

You've indicated "CDNs and ISPs must provide IPv6 support first". A number of them do. A number of them don't. The entire point of a preballot is to get a sense of what those numbers are, and for CAs that have contracts with those that do not support IPv6, how long would it take a reasonable CA to support it?

You've indicated it's not overly difficult, so is it a matter of 3 months? 6 months? 10 years? That's the set of information that's useful to discuss, rather than assume it will happen.

Consider "Real demand for it" being at least one browser with a non-trivial user base requesting it.

But besides that I'm a bit curious why Google would have even the slightest interest in revocation checking services and how they are accessed considering that its products don't check revocation in first place :-)

1) This isn't just about revocation checking. As I noted in the preballot, it's also about authorityInfoAccess for intermediates.
2) As I explained in the preballot, this also applies to servers' ability to fetch fresh OCSP responses.

I appreciate the feedback, Eddy, but your response seems mostly reactionary, without having read the proposal or justifications provided therein. It'd be helpful to know what concrete concerns you'd have and what it would take to address them.

Regardless, I don't think it's a good state in the present form that, for counter-example, a CA could provide an OCSP responder or AIA caIssuers solely available over IPv6, when as you note, there's a non-trivial majority of clients with IPv4-only stacks. So consider this proposal as a way to close that ambiguity as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150205/69aaf73b/attachment-0002.html>