What will need to implement draft-acme-ip on boulder?

After my PR for add support for draft-acme-ip on pebble merged, I looked at boulder code to implement on it too and searched possible problems about it.(like what’s the point of pebble only support?), and this is what I found in first hour…
This list is most likely incomplete and need many more untested

  1. all the things doen in pebble patch
    • creating a new identifier type constant in acme/common.go
    • updating the WFE to allow IP type identifiers in newOrder requests
    • updating the WFE to validate the IP identifiers
    • updating the TLS-ALP-01 implementation to properly handle IP address identifiers
    • updating the HTTP-01 implementation to properly handle IP address identifiers
    • updating the DNS-01 implementation to forbid IP address identifiers
    • updating the CA to issue certificates for orders with IP address identifiers using appropriate SAN entries with iPAddress type
  2. WFE(1/2) NewOrder doesn’t send Identifier, but just names as [ ]string to wfe.ra.NewOrder()
  3. update CAA lookup to see caa and upstream rdns address for ip. Or skip it as it doesn’t need to in ca/b baseline requirements
  4. LE need to create new policy about rate limit for certs with ip (what would be “base domain” for ip addresses?
  5. add PA test for IP address cert request about anything possible to send.
  6. add checks to block request to private IPs. but challenges won’t able to succeed on such ip anyway.
    some troublesome place about adding identifier type ip.
  7. those places hard-coded to make identifiers from (domain) name with type “dns”
    in most place it uses identifier.DNSIdentifier(), but in some places it doesn’t.
    • a. at line 348 performRemoteValidation() it gets only domain string as input and send it to rva’s PerformVlidation()
    • b. at va.go line 567, PerformVlidation()
    • c. ra.go line 2057, NewOrder() (※this don’t use function identifier.DNSIdentifier)

it looks like wfe check there is no identifier type other then DNS, then just send names to RA, and RA recreate identifiers with hard-corded identfiertype dns

I think update wfe1 and 2 to send full identifiers to RA, and update RA do deal with it.
it’s mostly the same problem that had on pebble, but things like CAA and ratelimit. is added on top of that.
and it’d be complex change that make many new joints on boulder. maybe even more then wildcard support.

3 Likes

Out of curiosity, where did you find that? In my mind CAA is still theoretically applicable to IP address identifiers, and there’s already a place to put them (the .in-addr.arpa. and .ip6.arpa. hierarchies)

1 Like

I didn’t actually find any such, just didn’t expected to rdns servers to capable to answer CAA.
and ipv6 caa address will lookup upstream caa for 32 times (as it get octet get a subdomain layer), this looks too much for a single lookup.
and classless rdns will make it harder: how we know there wouldn’t be blocking rule at /26?

2 Likes

Good points, those are some hard problems (maybe RDAP can help?). Looking more closely, it seems like CAA was only ever meant for domain identifiers anyway.

Sorry, was more of a question about WebPKI than ietf-acme-ip.

2 Likes

Thanks for the summary @orangepizza, (and of course for your Pebble work!).

Not sure if this was rhetorical but Pebble only support is useful as a reference implementation for a new draft (rough consensus and running code!). It’s already being used by down-stream ACME client implementors like Ansible.

I think this sort of planning/discussion would be best in a Boulder issue. We already have (a very lightly described) issue for this that could be a good place to consolidate the discussion: Boulder Issue 2706. @orangepizza Would you like to move some of your post to that issue?

The original issue calls out a few things that aren’t captured in your list:

  • We’d need to update our CP and CPS.
  • Unlike Pebble there would need to be robust unit and integration tests (this might translate into needing to do some acme python module work as well).
  • We would want to restrict IP subject certificate lifetime to <90days.

That last point about certificate lifetime is itself a small project. The Henry Ford model of certificate lifetime (You can have any lifetime as long as it’s 90 days…) has been a long-standing part of Boulder’s design and there are likely a few places where we rely on this in performance sensitive request paths.

Supporting ACME-IP in Boulder and the production Let’s Encrypt service is something we want to do but it’s a major project that is likely to be scheduled behind some other larger projects with more pressing need. We talked internally and the Boulder team thinks that given the overall complexity of the project and the number of areas of Boulder it will impact we feel most comfortable implementing ACME-IP ourselves. I don’t think we have the resources to coach an external contributor through this project end-to-end.

@roland had given some thought to this as well when working on the ACME-IP draft. I believe there may be some older discussion on the ACME WG mailing list about it. The tl;dr is that the work was put aside after there was limited interest within the IETF in using the reverse zones for CAA or anything related to security.

Thanks for opening this thread @orangepizza. While its unlikely to be something we can figure out in the short term I definitely think it’s valuable to keep refining the plan to implement ACME-IP and would love to help keep that discussion moving in https://github.com/letsencrypt/boulder/issues/2706

Thanks again!

4 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.