IP Address Certificates via ACME

[Ryan Hurst]

Hello,

Google Trust Services is considering issuing IP address certificates for its subscribers via ACME. 

Although the BRs permit the issuance of IP certificates, a number of concerns have been raised in the past highlighting that IP address validation can be less secure than domain validation. There are some conversations on this topic here https://lists.cabforum.org/pipermail/validation/2018-January/000712.html. Given this is not a common practice at this time we thought it would be useful to seek the communities feedback topic.

We believe the primary risk is that IP addresses can be assigned dynamically, a practice that is very common. This can lead to BygoneSSL (https://insecure.design/) type problems, and these are even more likely to occur in the context of IP address certificates because  a change in the control of an IP address can be much more frequent than a change in the control of a domain name.

We have considered a number of mitigation strategies. One would be to limit the re-use of IP address validation information to a very short period, for example 8 hours. This would mitigate the risk of issuance for an IP that is not under the control of the subscriber during a renewal.

An accompanying control would be to limit the validity period of such certificates to a short period, for example, 7 days. Those two controls combined limit the maximum period that a certificate may be valid for an IP that is not under the control of the subscriber to a little bit less than 7 days and 8 hours.

Another control that we have considered is limiting issuance of IP certificates to specific subscribers. This way we can define allow lists of IP addresses that each subscriber can issue IP address certificates for, after they have provided proof of assignment by the IANA or a Regional Internet Registry. This has challenges due to the quality of those registries though.

Any thoughts from the community and root programs on this topic would be greatly appreciated.

Ryan Hurst

Google Trust Services

[Ryan Sleevi]

On Tue, Jul 13, 2021 at 11:53 AM 'Ryan Hurst' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:

> Another control that we have considered is limiting issuance of IP certificates to specific subscribers. This way we can define allow lists of IP addresses that each subscriber can issue IP address certificates for, after they have provided proof of assignment by the IANA or a Regional Internet Registry. This has challenges due to the quality of those registries though.

Could you expand on your remarks about quality? I suspect this may be
tied to certain implementation assumptions, and it would be useful to
have those stated. For example, the distinction between, say, a WHOIS
vs RPKI implementation.

[Matthew Hardeman]

At least in as far as the two largest RIRs are concerned, there's a mechanism for the proper "owners" of the IP space to control the DNS delegation for the zones that are authoritatively the "reverse" zones for the IP space.  The right of control over these delegations is definitionally aligned to the ownership/registration of the underlying IP space.  This is part of the normal user interfaces and APIs utilized in the management of the IP space.  Information regarding these name spaces and their delegation can be found by chasing the references back from RFC5855 / BCP155.

The entirety of proof-of-control/proof-of-ownership in the WebPKI is otherwise aligned to ground-truth from DNS.  Why would a TXT record & CAA record check of the appropriate "reverse" zone not convey similar assurance?

Undoubtedly, this would allow handing a certificate for a given IP address or network that is not presently routed-to/terminated-at the certificate subscriber, but this it not unlike the WebPKI today where one's ability to alter, upon request of proof, TXT records in a given DNS name space gives me access to certificate issuance over that name space.

Another (though more convoluted) way to align to IP address rights of use would be to come up with a challenge based on some sort of contrived ROA signed by a certificate chaining to one of the RIR RPKI anchors, but this would be unwieldy even for the majority of those networks who have deployed RPKI because by a LARGE margin, most network operators have allowed the RIRs signing & issuing infrastructure to manage their RPKI certificates and signing function.  It seems unlikely that a lot of network operators would want to stand up an in-house RPKI CA in order to gain the ability to sign a challenge of this sort.

[Ryan Sleevi]

On Tue, Jul 13, 2021 at 12:34 PM Matthew Hardeman <mhar...@gmail.com> wrote:
> At least in as far as the two largest RIRs are concerned, there's a mechanism for the proper "owners" of the IP space to control the DNS delegation for the zones that are authoritatively the "reverse" zones for the IP space.

Could you be more explicit here about which two you're thinking of? I
think most network engineers would agree that the reverse zone lookups
are highly unreliable to reflect the actual deployed reality. That is,
I can understand and appreciate your focus on RIRs, but when
considering LIRs and other stakeholders, the reverse zones do not, in
practice, reflect the operational deployment.

> The entirety of proof-of-control/proof-of-ownership in the WebPKI is otherwise aligned to ground-truth from DNS. Why would a TXT record & CAA record check of the appropriate "reverse" zone not convey similar assurance?

There is past discussion in the CA/B Forum about this. Before
rehashing all this, it may be more useful if you can provide more
supporting details why you believe it _would_ be acceptable (as
remarked above).

That said, I'm not sure I understand the purpose of your question. You
seem to be speaking to the method of validation, which 3.2.2.5 of the
BRs addresses, but that seems orthogonal to Ryan Hurst's original
question.

> Another (though more convoluted) way to align to IP address rights of use would be to come up with a challenge based on some sort of contrived ROA signed by a certificate chaining to one of the RIR RPKI anchors, but this would be unwieldy even for the majority of those networks who have deployed RPKI because by a LARGE margin, most network operators have allowed the RIRs signing & issuing infrastructure to manage their RPKI certificates and signing function. It seems unlikely that a lot of network operators would want to stand up an in-house RPKI CA in order to gain the ability to sign a challenge of this sort.

I'm not sure why you say "more convoluted" here (compared to... what?
And what are your priorities that you're optimizing for).

This provides less ambiguous assertions, and which unambiguously chain
to a source of truth, and in a way that can be assessed for time
validity and freshness, not to mention avoiding the contextual
overloading of other data sources - as the RPKI exists for this very
purpose/problem (of asserting authorization for IP address spaces)

[Matthew Hardeman]

On Tue, Jul 13, 2021 at 12:39 PM Ryan Sleevi <ry...@sleevi.com> wrote:

On Tue, Jul 13, 2021 at 12:34 PM Matthew Hardeman <mhar...@gmail.com> wrote:
> At least in as far as the two largest RIRs are concerned, there's a mechanism for the proper "owners" of the IP space to control the DNS delegation for the zones that are authoritatively the "reverse" zones for the IP space.

Could you be more explicit here about which two you're thinking of? I
think most network engineers would agree that the reverse zone lookups
are highly unreliable to reflect the actual deployed reality. That is,
I can understand and appreciate your focus on RIRs, but when
considering LIRs and other stakeholders, the reverse zones do not, in
practice, reflect the operational deployment.

I'm calling out ARIN & RIPE particularly as having robust reverse DNS infrastructure and provisioning.  In my experience as a network operator reverse DNS is precisely as robust as the resource holder (the first-order LIR / entity holding the IP space registration) wishes and configures it to be.  The consequences of underprovisioning or not provisioning it would, within the context of this discussion, be visited upon the network operator with both the ability and motivation to address any issues in the DNS infrastructure which are causing them to have certificate issuance issues.

To add a bit of additional context, it is my presumption that the base of subscribers interested in sanIPAddress certificates is going to be larger entities and network operators who will tend to be direct assignees.  In the alternative, they are likely to be direct customers of said operators and able to provide economic incentive to get any reverse DNS delegation issues worked out. 

> The entirety of proof-of-control/proof-of-ownership in the WebPKI is otherwise aligned to ground-truth from DNS.  Why would a TXT record & CAA record check of the appropriate "reverse" zone not convey similar assurance?

There is past discussion in the CA/B Forum about this. Before
rehashing all this, it may be more useful if you can provide more
supporting details why you believe it _would_ be acceptable (as
remarked above).

That said, I'm not sure I understand the purpose of your question. You
seem to be speaking to the method of validation, which 3.2.2.5 of the
BRs addresses, but that seems orthogonal to Ryan Hurst's original
question.

The purpose of the question was my own curiosity -- as well as some concerns with the methods --  as I had just reviewed the 3.2.2.5 methods and find the 3.2.2.5.3 method to be ridiculous.  Any compromise of the direct use of the reverse zone would also give rise to vulnerability in 3.2.2.5.3 and 3.2.2.5.3 also simultaneously adds external dependencies (a domain) and parties (domain registry, domain registrar) which increases opportunities for exploitation and for unreliability.

 

> Another (though more convoluted) way to align to IP address rights of use would be to come up with a challenge based on some sort of contrived ROA signed by a certificate chaining to one of the RIR RPKI anchors, but this would be unwieldy even for the majority of those networks who have deployed RPKI because by a LARGE margin, most network operators have allowed the RIRs signing & issuing infrastructure to manage their RPKI certificates and signing function.  It seems unlikely that a lot of network operators would want to stand up an in-house RPKI CA in order to gain the ability to sign a challenge of this sort.

I'm not sure why you say "more convoluted" here (compared to... what?
And what are your priorities that you're optimizing for).

In this instance, I've used the term "more convoluted" to stand in for solutions which might bolt onto an extant authorization infrastructure but could easily misapprehend the infrastructure and deployment topology underpinning that scheme.

I don't have an agenda or priority here, per se.  I do believe that IP address resource holders should, in principle, be able to acquire certificates with SANs which reference the set of -- or, more often, some subset of -- their IP resources.  I also believe that some of the validation methods as presently defined in the BRs are on the weak side while also frequently less conducive to automation.

So that I'm crystal clear, I don't have any objections or concerns specifically surrounding Ryan Hurst's proposed issuances by Google Trust Service.

[Ryan Hurst]

Frankly the concerns around the quality of those registries are more antidotal, we have heard that these registries often contain outdated information, in particular contact details, and are difficult to get updated with correct data. With that said we would love to learn that this is not the case.

The larger concern though is the adoption of deployment models where IP address "ownership" is more ephemeral, for example, in the case of cloud services maybe you spin up a VM with a dedicated IP for hours and then shut the VM down and that IP goes back into the pool of addresses to be reassigned to another user.

Based on the above we have been leaning to proof based mechanisms with frequent re-verification but even these have their failings.

Ryan Hurst

Google Trust Services

[Matthew Hardeman]

It's possibly more "truthy" than true these days.

In recent years, significant improvement in registry data quality (at least at ARIN) has been achieved by requiring periodic confirmation that email touches by ARIN to the various contact points have succeeded.  Otherwise those contacts get listed as unreachable and eventually removed, which causes registration renewal issues, which gets those issues fixed...

Still, there is a non-WebPKI matter where another cloud player clearly did some risk modeling and came up with a stricter assessment, albeit for an even riskier proposition: route advertisement.  Amazon has a BYOIP service.  I, as an IP network resource holder with resources from ARIN, can cause Amazon to advertise a subset of IP space that is allocated to me.  To do that, I need to not only create RPKI ROAs for the intended subnet but with Amazon's AS numbers, but in addition Amazon requires that I modify the RDAP/WHOIS entry for the associated network record in order to publish an RSA public key.  I then have to use that public key to sign (as I recall, a pipe-delimited record) binding an authorization for that subnet to my own AWS account ID.  There's more on it here, if interested: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html

I'm not suggesting that the WebPKI requires anything like this.  But to your point, I think it suggests that Amazon looked at the registry data question and decided that proof of ability to make a change to the registry data was more valuable than current info in the registry, at least when it came to getting them to stick their neck out on a network route advertisement.

[Ryan Sleevi]

On Tue, Jul 13, 2021 at 2:31 PM Matthew Hardeman <mhar...@gmail.com> wrote:
> I'm calling out ARIN & RIPE particularly as having robust reverse DNS infrastructure and provisioning. In my experience as a network operator reverse DNS is precisely as robust as the resource holder (the first-order LIR / entity holding the IP space registration) wishes and configures it to be. The consequences of underprovisioning or not provisioning it would, within the context of this discussion, be visited upon the network operator with both the ability and motivation to address any issues in the DNS infrastructure which are causing them to have certificate issuance issues.
>
> To add a bit of additional context, it is my presumption that the base of subscribers interested in sanIPAddress certificates is going to be larger entities and network operators who will tend to be direct assignees. In the alternative, they are likely to be direct customers of said operators and able to provide economic incentive to get any reverse DNS delegation issues worked out.

Historically, browser vendors have tended to reject this model of
outsourced risk; namely, the "well, it's your own fault if the
information is bad". Web browsers have a duty of care to users, and so
while I agree that the truthiness to the first order resource holder
has significantly improved, the complexities of modern networking and
deployments mean that both the likelihood of correct provisioning -
and, in this case, the potential harm from incorrect provisioning -
make this an unacceptable tradeoff to just say "whoopsie doo, that's
on you".

With respect to the considerable effort spent improving 3.2.2.4 of the
BRs, a big shift was in trying to make explicit the validations, as
well as the consequences of certain (seemingly unrelated to
certificates) decisions. Methods that require explicit involvement,
even if more bootstrapping work, end up better for security in the
long run. See, for example, the transition from "any arbitrary
webpage" to being "/.well-known/" (which has known security
consequences if you allow arbitrary access, independent of certs) and
ACME.

> The purpose of the question was my own curiosity -- as well as some concerns with the methods -- as I had just reviewed the 3.2.2.5 methods and find the 3.2.2.5.3 method to be ridiculous.

To be clear, I think this is mostly independent of Hursts' question.
There's no disagreement, even within the CA/Browser Forum, that the
3.2.2.5 methods are terrible and in need to overhaul, similar to
3.2.2.4. To some extent, these problems are mitigated by the fact that
"no one is really doing it" (at scale), and I suspect that part of the
motivation to Hursts' question, at least based on appearances, is "How
can we (GTS) do better than the minimum, given that we all agree there
are risks".

That's desirable behaviour for CAs to do, and to share their analysis
(as has been done). Where I struggled was figuring out your reply and
trying to understand if you were advocating for doing more than being
proposed, doing less than being proposed, or if it was mostly
rhetorical on the meta-point of IP addresses in certs (and how that
tied in to the questions posed)

[Ryan Sleevi]

On Tue, Jul 13, 2021 at 2:35 PM Ryan Hurst <r...@google.com> wrote:
> The larger concern though is the adoption of deployment models where IP address "ownership" is more ephemeral, for example, in the case of cloud services maybe you spin up a VM with a dedicated IP for hours and then shut the VM down and that IP goes back into the pool of addresses to be reassigned to another user.

How/when would these interact with the Web PKI, and why is that desirable?

That is, the solution space being described here appears to be for
machine-to-machine interactions, and that's very explicitly something
that should not be overloading the Web PKI for. If it's for
user-to-machine interaction, or in this cloud services, why isn't the
cloud provider assigning unique names to these? Have I misunderstood
something about the use case?

I have a larger set of thoughts here about this problem space, but I
think it might be most useful to articulate the "why", since that will
inevitably constrain alternative solutions, but also help better
inform anticipated risks.

[Ryan Hurst]

I think you're characterization of our goal here is right. That is, we believe this to be allowed today but we would like to do better than the minimum should we move forward. This is, for example, why in the discussed the significantly reduced validity periods and data re-use periods as further mitigations. This approach does introduce some challenges, namley at least one of the potential consumers have indicated to accomodate SLAs period of 14 days might be required.

As for why customers have told us they use IP address WebPKI certificates, so far I would say the use cases fall into one of two categories. The first being cases where the server is being accessed by a browser for cases where latency is very important, for example in streaming.  The second being cases like DoH were the identity of the server IS the IP address. These are both legitimate concerns from our perspective and we do believe all certificate lifecycle should be automated so we would like to support them if it is reasonable to do so.

Ryan Hurst

Google Trust Services

[Ryan Sleevi]

On Tue, Jul 13, 2021 at 3:58 PM Ryan Hurst <r...@google.com> wrote:
> As for why customers have told us they use IP address WebPKI certificates, so far I would say the use cases fall into one of two categories. The first being cases where the server is being accessed by a browser for cases where latency is very important, for example in streaming.  The second being cases like DoH were the identity of the server IS the IP address. These are both legitimate concerns from our perspective and we do believe all certificate lifecycle should be automated so we would like to support them if it is reasonable to do so.

I'm hoping you can expand with more detail here. You are correct that automation is a very positive goal, but as you've also highlighted, there's concerns about potentially needing to restrict who can obtain such certificates. For example, if it was "just" for DoH, we're talking a number of certs that I could (at present) count with my digits, and likely for the next ten years, count based on the number of bottles of beer on the wall.

So the former case is perhaps more interesting, and non-obvious why an IP address certificate is at all desirable from a security/risk perspective. It's unclear, for example, if the suggestion of latency is saying "DNS latency is too slow for this use case" - which certainly seems like it deserves some empirical data and detail. Further, the description of spun-up/spun-down VMs does seem to fit the very risk model that folks have been concerned with allowing IP certificates to exist at all: the fact that the same IP address can refer to the same operating entity (e.g. Google Cloud's ARIN-assigned network block), but different logical entities (different customer tenants), potentially in ways that allow for confused deputy attacks (noting that some have been in the news recently regarding GCP and private-use IP addresses).

I realize the above questions are probably uncomfortable, for a few understandable factors. GTS has likely already explored options with their customers, and feel like the question is not "why IP", but "how IP", and this is just relitigating past decisions. Equally, GTS may not be comfortable sharing these details in a public forum, perhaps because they're internal reasons or unannounced products. Private conversations are something GTS has explored in the past, but recognizing the failure modes of those, this is now an uncomfortable place.

I appreciate that GTS is asking "How can we do this, not just within the confines of the (presently insecure) BRs, but in a way that helps keep users safe". It's somewhat necessary for us (the community) to ask "Are you sure you really need this at all?", especially because the proposed use case definitely seems to be manifesting folks' worst fears about IP addresses. But equally, there's a challenge in the answer here, because it's nuanced.

The "What's the secure way to issue IP address certs" depends on how those IPs are managed and allocated. Where the CA is also the Subscriber (or an Affiliate of the Subscriber), you may have greater insight into the IP address allocation policies, and the goal should be that "Certificate lifetimes are shorter than the IP allocation process". If IPs are measured in O(minutes), then the certs should be measured in O(minutes). The Web PKI is still working through the answers for DNS (registration is measured O(1 year), but we know in practice, allocation is measured in much shorter timescales). However, this is much messier when the CA is not the Subscriber - because the CA then loses the necessary insight into the IP allocation strategy, and all bets are off. The goal of asking these questions is to try to help extract principles and goals that can guide the answer, not just for your specific case, but for CAs in general.

My default reaction is "The best decision a CA can make is to not play the (IP address cert) game", but that's not to say there are never legitimate cases; just, they're fewer, and need to be approached carefully. This thread seems to suggest GTS recognizes that, and that's why the goal is to collaborate, in public, on what it means in practice to "approach carefully".

[Cynthia Revström]

Hi,

I thought I could provide some input here as this is something I have looked at in some detail for quite a while and I have a decent chunk of experience with the RIR/networking bits.

1. I think you have to trust some piece of information given by the RIR and you should look at what that piece of information is rather than trying to remove RIRs from this equation.

2. There are far worse and more likely things that could happen as a result of data in RIRs being incorrectly delegated that some other methods of validation are vulnerable too as well.

3. Given that one of the main use cases of this would probably be DoH which is probably likely to be anycast, HTTP validation seems like an overly complicated and hacky option.

4. As Matthew pointed out, RPKI should really be a last resort option as it is unlikely to work for most as pretty much everyone (except maybe the tech/network giants) will be using hosted RPKI* and can't issue anything except normal ROAs. (* = PKI hosted and managed by the RIR/NIR)

5. While Reverse DNS is not normally used for very critical data and the data could sometimes be stale, I would imagine that being quite rare for NS delegations and is mostly just the PTR records themselves.

6. Contact data in the WHOIS database could often be outdated for admin and tech contacts I imagine but I don't think that is nearly as true with abuse contact data which other orgs use for verification. Also at least the RIPE NCC requires resource holders to keep this data up to date.

In my opinion, RPKI is the most secure option as it secures far more critical things but will be an infeasible option for pretty much anyone as even the people using delegated RPKI are not using inhouse custom software for it.

I would consider abuse contact information to be an easy (but manual) method of validation.

I think combining abuse contact email and reverse DNS TXT validation is far more secure than many current practices for domain issuance and for both to be invalidly directed at a malicious party in this way seems unlikely and would probably often violate RIR policy.

As the abuse contact might be manual, I feel like that validation could probably have a longer life, something like a year if the contact email address hasn't changed. (but the DNS TXT validation only lasting for 8h or something)

I have probably forgotten to mention parts that might not be obvious so please ask if something is unclear.

-Cynthia

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHECxket0DOObX3PL0YvJQ2%3D%2BTrupDzWUZuZ7Qw2GsbNww%40mail.gmail.com.

[Matthew Hardeman]

4. As Matthew pointed out, RPKI should really be a last resort option as it is unlikely to work for most as pretty much everyone (except maybe the tech/network giants) will be using hosted RPKI* and can't issue anything except normal ROAs. (* = PKI hosted and managed by the RIR/NIR)

Hehe.   Hi, Cynthia.   If I recall correctly, you may be one of the only people I'm aware of who actually has stood-up infra to do your own ROA signing & publication. 

 

In my opinion, RPKI is the most secure option as it secures far more critical things but will be an infeasible option for pretty much anyone as even the people using delegated RPKI are not using inhouse custom software for it.

I would consider abuse contact information to be an easy (but manual) method of validation.

I think combining abuse contact email and reverse DNS TXT validation is far more secure than many current practices for domain issuance and for both to be invalidly directed at a malicious party in this way seems unlikely and would probably often violate RIR policy.

That's true.  The other nice thing about TXT on the reverse zone is that any IP resource holder who wants that to happen can get that to happen while simultaneously people who are temporarily assigned an IP address will almost certainly not be able to get that to happen, or if they can, it would generally be by special agreement.

I can envision someone like GCP, for one example, offering whatever their equivalent of Amazon's "Elastic IP" is with an option to get a TLS cert with the IP address, for an additional cost, that cost covering the cost of keeping that IP address out-of-use / on-hold to recycle after the cert validity has expired.

[Ryan Sleevi]

Thanks for chiming in! I do think we might be narrowly focusing on a small point of the overall discussion, and while I do believe it's important and worth resolving at some point, I don't know that it's critical we resolve it now.

On Tue, Jul 13, 2021 at 6:12 PM Cynthia Revström <m...@cynthia.re> wrote:

1. I think you have to trust some piece of information given by the RIR and you should look at what that piece of information is rather than trying to remove RIRs from this equation.

<snip> 

 

5. While Reverse DNS is not normally used for very critical data and the data could sometimes be stale, I would imagine that being quite rare for NS delegations and is mostly just the PTR records themselves.

I think  this reply may be making some assumptions about my concerns that I've not at all stated on this thread, and thus perhaps leading to an incorrect conclusion.

The reply here seems to assume my concern is "You can't trust ARIN", but that couldn't be further from the truth. Rather, the deployed reality is that multiple parties are frequently involved in the IP routing - this is why, for example, RPKI isn't simply "flat" at one level - and the issue is that in order for a reverse DNS solution to be acceptable, every party in the chain needs to perfectly execute, and the incentives are simply not there. For example, ARIN assigns a block of IPs to Entity Foo, who is a provider for Entity Bar, who then further delegates to customers Baz, Bat, and Quux. For Quux to be secure, you need Foo and Bar to perfectly execute. And if those IPs are later reassigned from Quux to Baz, if Bar doesn't maintain that information/disclosure, things fall apart.

To reiterate: I'm not trying to remove RIRs from the equation; if anything, I'm trying to highlight that RIRs are the only entities you can trust (even if not all RIRs are equal here, such is life), but the moment you introduce the complex relationships and subordination, naive solutions that make execution security critical fall apart.

RPKI reflects the complexity of expressing those relationships, and yes, it's far from widely deployed, but it's unambiguous and explicit in ways that, say, reverse DNS are not.

In particular, I'm hoping we can save the discussion about TXT in the reverse zone for a separate discussion, both noting it's been discussed in the past and it's a broader topic, because I don't think that's strictly germane to the questions at play here.

[Cynthia Revström]

Hi,

On Wed, Jul 14, 2021, 00:48 Ryan Sleevi <ry...@sleevi.com> wrote:

Thanks for chiming in! I do think we might be narrowly focusing on a small point of the overall discussion, and while I do believe it's important and worth resolving at some point, I don't know that it's critical we resolve it now.

That's a fair point as for GTS's case here that might not be the best solution.

I have posted a reply below regardless as I might not have phrased it well.

I think  this reply may be making some assumptions about my concerns that I've not at all stated on this thread, and thus perhaps leading to an incorrect conclusion.

The reply here seems to assume my concern is "You can't trust ARIN", but that couldn't be further from the truth. Rather, the deployed reality is that multiple parties are frequently involved in the IP routing - this is why, for example, RPKI isn't simply "flat" at one level - and the issue is that in order for a reverse DNS solution to be acceptable, every party in the chain needs to perfectly execute, and the incentives are simply not there. For example, ARIN assigns a block of IPs to Entity Foo, who is a provider for Entity Bar, who then further delegates to customers Baz, Bat, and Quux. For Quux to be secure, you need Foo and Bar to perfectly execute. And if those IPs are later reassigned from Quux to Baz, if Bar doesn't maintain that information/disclosure, things fall apart.

To reiterate: I'm not trying to remove RIRs from the equation; if anything, I'm trying to highlight that RIRs are the only entities you can trust (even if not all RIRs are equal here, such is life), but the moment you introduce the complex relationships and subordination, naive solutions that make execution security critical fall apart.

I don't think this at all common in the real world, I imagine almost all deployments would be IANA -> RIR -> LIR/ISP. some will have 2 RIRs in there for cases when the /8 prefix might be administered by ARIN and a /16 is administered by RIPE NCC because of transfers or legacy reasons. (just an example)

but assuming you can trust all RIRs (which RPKI effectively assumes) then there would rarely be any other party involved.

Maybe some cases would have a large carrier delegate to a small ISP but then you are relying on that carrier for so much more and they are the resource holder according to the RIR probably.

Also do note that you have the same thing with the same parties in RPKI.

-Cynthia

[Matthew Hardeman]

On Tue, Jul 13, 2021 at 4:24 PM Ryan Sleevi <ry...@sleevi.com> wrote:

On Tue, Jul 13, 2021 at 3:58 PM Ryan Hurst <r...@google.com> wrote:
> As for why customers have told us they use IP address WebPKI certificates, so far I would say the use cases fall into one of two categories. The first being cases where the server is being accessed by a browser for cases where latency is very important, for example in streaming.  The second being cases like DoH were the identity of the server IS the IP address. These are both legitimate concerns from our perspective and we do believe all certificate lifecycle should be automated so we would like to support them if it is reasonable to do so.

I'm hoping you can expand with more detail here. You are correct that automation is a very positive goal, but as you've also highlighted, there's concerns about potentially needing to restrict who can obtain such certificates. For example, if it was "just" for DoH, we're talking a number of certs that I could (at present) count with my digits, and likely for the next ten years, count based on the number of bottles of beer on the wall.

Really?  With utilization of DoH going up by browsers, I expect to see more SMBs (and router/fw vendors to SMBs and cloud network appliance vendors to SMBs) pushing corporate DoH servers to allow for the full feature set within modern TLS (eSNI, etc) while still logging destinations visited/connected-to and/or blocking by target domain.

 

So the former case is perhaps more interesting, and non-obvious why an IP address certificate is at all desirable from a security/risk perspective. It's unclear, for example, if the suggestion of latency is saying "DNS latency is too slow for this use case" - which certainly seems like it deserves some empirical data and detail. Further, the description of spun-up/spun-down VMs does seem to fit the very risk model that folks have been concerned with allowing IP certificates to exist at all: the fact that the same IP address can refer to the same operating entity (e.g. Google Cloud's ARIN-assigned network block), but different logical entities (different customer tenants), potentially in ways that allow for confused deputy attacks (noting that some have been in the news recently regarding GCP and private-use IP addresses).

I suspect it's less about raw DNS infrastructure latency and typical case matters and more a case of, for example, certain embedded streaming boxes and/or certain software stacks handling DNS queries poorly or responding badly to transient DNS failures. 

[Matthew Hardeman]

On Tue, Jul 13, 2021 at 5:48 PM Ryan Sleevi <ry...@sleevi.com> wrote:

In particular, I'm hoping we can save the discussion about TXT in the reverse zone for a separate discussion, both noting it's been discussed in the past and it's a broader topic, because I don't think that's strictly germane to the questions at play here.

This has helped me to better comprehend my own reasons for commenting on this particular matter at this particular time.

The reason I've gone into the validation method rabbit hole at this juncture is that while I don't think there's anything nefarious in GTS' intent to codify and issue sanIPAddress certs, I do actually have strong opinions about what entities should be able to achieve getting a certificate which covers an IP address.

Specifically, I think certificates issued upon the informed consideration and intent of the registered resource holders (those directly allocated or assigned IP space by an RIR) and those entities downline of those resource holders who are specifically being intentionally delegated authority over certain management aspects of a subset of that DNS space should definitely be able to get certificates which cover their IPs.

On the other hand, it's ludicrous to me that under 3.2.2.5.1, a CA would have leave to issue a certificate covering an IP address merely because a person was able to simultaneously communicate with the CA and answer port 80 on the IP address in question.

It is almost assuredly the intent of the resource holder in the case of a dynamic pool of IP addresses serving a large residential subscriber base that any given individual subscriber should NOT be able to get a certificate covering that IP they're momentarily assigned.  That could change any time.

On the other hand, it's not unlikely that a small biz subscriber served by an ISP with a static /29 might be a case where the ISP intends to allow such an issuance.  Perhaps even in automated fashion.  A DNS delegation of the relevant reverse zone is, from an IP network management perspective, probably a pretty decent proxy for that.

But specifics of validation methods aside, I think the root programs for several different use cases which come to mind should be able to allow and accommodate the issuance of sanIPAddress certs.  However, the bar should be a bit higher than "I can serve you a random value of your choice at a pre-defined standardized challenge URL."

In a cloud provider use case, I think as the IP resource holder, a cloud provider is within their rights to get certificates issued which cover their IP address resources, but I would also suggest that it's likely improper to have key material in the hands of a client that is likely to outlive the IP address' association with the client.  One way to underwrite over that risk would be to use a short validity period coupled with a "don't recycle until X" policy.  Maybe there's a way to tag the IP address as not re-assignable to another client until after the cert validity has expired.

[Matthew Hardeman]

On Tue, Jul 13, 2021 at 6:01 PM 'Cynthia Revström' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

Also do note that you have the same thing with the same parties in RPKI.

Indeed, complex delegation chains are entirely possible in the RPKI.

Furthermore, it bears mention that the RPKI has a very narrow and specific stated purpose: to provide a cryptographically secure mechanism for the publication of authoritative statements of authorization for a given network entity (an AS) to originate a routing advertisement over a particular network prefix.

As a network operator, this boundary is NOT the same boundary that I would choose to have applied as to whether a client who receives IP space delegated from me should qualify for a TLS certificate covering that IP space.

Succinctly, one of these is the privilege of influencing the routing policy and path for traffic to arrive to the IP address(es) in question while the other is about getting the full benefit and privilege of use of the IP address(es) and the traffic that the upstream provider has arranged to arrive at said address(es).

[Matthew Hardeman]

On Wed, Jul 14, 2021 at 8:02 AM Paul Wouters <pa...@nohats.ca> wrote:

This process is almost never properly supported. Getting a reverse
classless delegation as per RFC 2317 is really difficult.

A thing that holds it back is that there's presently little cause to press for it.  If something required it, it could be more available rapidly.  As it is, reverse zones are definitely available to those with direct IP space from the RIRs and to those with enough clout and tenacity to press for it from their ISP. 

[Job Snijders]

Dear all,

I'm responding to the request for 'any thoughts on this topic' related
to:

> Google Trust Services is considering issuing IP address certificates
> for its subscribers via ACME.

It was brought to my attention that subsequent replies contained the
phrase 'RPKI', which is a topic I have a professional interest in. I
hope I can contribute what I know to this group, I'm available for any
questions you might have.

The following is not a reflection on whether or not it is a good idea to
issue IP address certificates, but rather some notes on where to start
looking if one wants to design an ACME challenge in relationship to the
RPKI.

How to use the RPKI?
====================

Earlier on in the thread someone mentioned: "a challenge based on some
sort of contrived ROA". There is a specific object profile for this kind
of purpose to make it less contrived. To build arcs from the RIR
operated RPKI towards arbitrary digital objects, a general purpose
attestation mechanism dubbed 'RSC' can be used to construct RPKI-based
challenge/responses.

The advantage of using 'RSC' is that it exists outside the realm of BGP
routing, and outside the RPKI's publication system (in contrast to
for example ROA objects).

The draft is stable, multiple proof-of-concept implementations exist.
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc

Who has the RPKI private keys?
==============================

This is tricky. Any intermediate CA in the validation chain from the
RSC's EE certificate, all the way up to the Trust Anchor, will have the
RSC's eContent IP address listed as subordinate resource. The RPKI can
be used to obtain a non-repudiated attestation the issuer was capable of
generating a RSC object, but the RPKI itself cannot tell you WHO
generated it. However, I think in many scenarios it doesn't matter who
overcame a particular challenge.

See the following draft for more thoughts on this aspect:
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-identity

Kind regards,

Job

[Cynthia Revström]

Hi,

I mainly just want to point out that from what I have heard there is a "competitor"(?) to RSC which is RTAs.

I have not yet read the details of either but I just want to note that it does exist as someone pointed it out to me.

draft spec: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00

-Cynthia

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/YO80VxgyuNoubXh3%40snel.

[Matthias Merkel]

There is at least one CA already issuing purely DV validated IP address certificates based on HTTP validation so any additional measures are good. 

The usage of RPKI for this is likely too complicated and not easy to integrate into ACME. Most organizations don't run their own RPKI servers, and RIR-provided hosted RPKI would not (immediately) support the new functionality. It is questionable whether RIRs would ever implement this given the likely low demand. 

If Google plan to offer this product to select customers only, it may be worth doing OV on the organization and verifying IP ownership via RIR whois, along with using HTTP validation for DV. As far as I know, this is the approach most CAs take for IP address certificates and this would make it possible to allow issuance via ACME without making too many (any?) changes to existing ACME clients. 

Matthias Merkel

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKw1M3MiNbC9cA__WwCFbeEsZo8u0HZs2jiiA5m1MwXk%3DL7WoA%40mail.gmail.com.

[Cynthia Revström]

Hi Matthias,

I believe this is about how it could be done in an automated way that isn't subject to human error so OV would be far from ideal.

Purely HTTP DV is not a great solution either.

I think we are probably looking at security more than easiest to implement quickly here.

-Cynthia

[Matthew Hardeman]

I believe the point that Matthias Merkel may be making is that there are, at present, multiple trusted CAs offering up TLS Server certs with ip address SANs and CNs upon the strength of domain validation only, which may include as little as proof of ability to control port 80 on the subject IP address.

In so far as that is concerned, I don't think it's particularly worrisome that GTS is considering also issuing SAN ipAddress certificates, provided they do so with the same or higher standard of validation.  If it's presently acceptable practice, I suppose it's presently acceptable practice.

I think this is an area ripe for re-examination, but I do ultimately agree that such re-examination can happen outside the scope of Google's inquiry into the acceptability of the practice.