Part of both answers:
Disclaimer: I am not a QSA. And I'm straying farther into opinion here than I prefer to, so apply salt in grain form.
New answer following edit of question:
There are two changes with DSS 3 that bear on what you seem to be flirting with
- the addition of the new SAQ A-EP category.
- the back alley tussle that has been iframes versus javascript
which keeps threatening to break out into some form of
official guidance.
Both of these items are concerned with the provenance of credit card transaction flow. If I go to website X, and click "Check Out" from their shopping cart, I go somewhere to enter my credit card details. Where is that somewhere? How do I know it's where I'm meant to be? How do I know it's not routing my traffic through Bulgaria first?
Your business appears to be a traffic middleman. Voila, you're exactly what PCI is moving towards avoiding, or at least securing. You want your clients to seamlessly send traffic your way and you'll provide value X. But PCI doesn't want traffic seamlessly redirected unless there's sufficient security - to make sure, for example, no one can edit the process to use a different (malicious) checkout page.
You route traffic based on analysis. Great! That means an attacker can use you to reroute traffic. In PCI terms, that means you're either in scope or not permitted. And as a service provider who has stayed out of scope in the past, that means something's likely to change.
Now, the provenance issues are not laid out clearly. I can't point to DSS 3 section 13.7 which says what you're doing is addressed. But I can tell you that QSAs are going to start asking questions like "And this company does what? They middle all your HTTP traffic, including the traffic that sends people to shopping cart and checkout?" Then they'll want to see your service provider certification, because as per the definition of Service Provider:
This also includes companies that provide services that control or
could impact the security of cardholder data.
So, yeah, you could end up with problems as the shift to DSS 3 progresses. I still don't feel confident I understand your business, so I can't say anything for sure, but it you're middling traffic, you're on the list and may lose customers if you're not a certified service provider. (Prolexic isn't. Akamai is. Who can say?)
Original answer below:
I recently performed a line-by-line comparison of PCI DSS v2 versus v3, and I don't recall anything within the DSS itself that would impact the traversal of HTTPS traffic across a provider. Section 4 deals with the encryption of "cardholder data across open, public networks" and would be the obvious place to look, and that's barely changed.
That being said, two caveats:
1) The DSS is not the only thing to pay attention to. The wording on the SAQs, if they apply to the businesses in question, and various other guidance papers that elaborate on the meaning for QSAs are also important.
2) It's not completely clear to me that your service is simply a conduit of encrypted traffic. You state that your clients "re-point their DNS to our application's IP address and our application will analyse the traffic and then route as appropriate." The phrase "analyse the traffic" will lure any QSA in for a deeper look. You shouldn't have much to work with for analysis, in the case of HTTPS; you would have to allow the SSL negotiation through to the true backend to nail up HTTPS before the channel was secure from you, and if that's all you're doing, your service isn't doing much. In short, I don't feel we have enough details about your service to give you solid advice.
