[cabfpub] Preballot for IPv6 Support

[Ryan Sleevi]

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>
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] *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> 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/20141216/1279fbe5/attachment-0003.html>