Implement RFC 8738: ACME IP Identifier Validation

[rolandshoemaker]

Implementation before standardization, it's a thing we should probably do.

For LE would this require a CP/CPS update before it could be deployed?

[rolandshoemaker]

For LE would this require a CP/CPS update before it could be deployed?

Yes, CPS 7.1.5 restricts issuance of certs for IP addresses.

[rolandshoemaker]

Open questions:

• Do we want to restrict any CIDRs (i.e. those held by ISPs)?
• Do we want to reduce the lifetime of certs containing IP addresses?

cc @jsha @cpu for thoughts

[jsha]

Definitely yep to both.

[rolandshoemaker]

Definitely yep to both.

Any thoughts on determining the values of either? Not really sure how we'd go about figuring out which CIDRs to block, is there a public CIDR list?

[jsha]

Oh, I misread; was thinking of private CIDRs, which of course we want to block. Blocking CIDRs belonging to ISPs seems counterproductive; I expect home servers to be a popular use case for IP certs. You should also ping the Technical Advisory Board for thoughts.

[orangepizza]

copied from forum:

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

all the things done 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


WFE(1/2) NewOrder doesn’t send Identifier, but just names as [ ]string to wfe.ra.NewOrder()
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
LE need to create new policy about rate limit for certs with ip (what would be “base domain” for ip addresses?
add PA test for IP address cert request about anything possible to send.
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.
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)

and from discussion on top
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.

…

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. likely even more then wildcard support.

[cpu]

I think update wfe1 and 2 to send full identifiers to RA, and update RA do deal with it.

@orangepizza One thing I forgot to mention on the forum thread: We would only want to implement ACME-IP for the ACME v2 RFC 8555 API, not the legacy ACME v1 API.

[orangepizza]

I think update wfe1 and 2 to send full identifiers to RA, and update RA do deal with it.

@orangepizza One thing I forgot to mention on the forum thread: We would only want to implement ACME-IP for the ACME v2 RFC 8555 API, not the legacy ACME v1 API.

it was more about as current WFE send order domains as []string and RA rebuild []Identifier with hard-corded dns type, but it need to change WFEs to send []Identifier and RA receive []Identifier as input if we want to handle anything other then DNS. by the way why it does this unpack-and-repack?

[HLFH]

I expect home servers to be a popular use case for IP certs.

And KVM over IP switches.

[dumblob]

I can see IANA review state: IANA OK - Actions Needed in https://datatracker.ietf.org/doc/draft-ietf-acme-ip/?include_text=1

Can we do something to speed things up a bit around implementing support for IPs in ACME?

[tdelmas]

Also, Let's Encrypt CP is updated in that direction: letsencrypt/cp-cps@b9e9a56...bc0499a#diff-43f79d14d36303bbae3da9268d7a2238R361-R399

[dumblob]

@tdelmas thanks for the pointer. So the certificate policy for IPs seems to be there. That's always good news. Do you happen to know whether there is any (preliminary/subject_to_change) schedule when this new policy could get implemented?

[rolandshoemaker]

The RFC is progressing through the IETF process, there is nothing we can do to speed that process up ourselves, we just have to wait.

We also don't have any specific timeline for implementing support for acme-ip, although it is likely it will happen sometime this year.

[dumblob]

We also don't have any specific timeline for implementing support for acme-ip, although it is likely it will happen sometime this year.

Ok, didn't expect there is no plan currently. Anyway, thanks for the valuable info. If anything should change, keep us posted.

[bortzmeyer]

The RFC is progressing through the IETF process, there is nothing we can do to speed that process up ourselves, we just have to wait.

We also don't have any specific timeline for implementing support for acme-ip, although it is likely it will happen sometime this year.

RFC 8738 is now published.

[maertsen]

Apple iOS 16 (fall 2022) will autodiscover and use encrypted DNS provided by “designated dns resolvers” when the resolver’s IP address provided in DHCP is included as SAN in the resolver’s certificate for DNS over TLS or DNS over HTTPS.
See https://mailarchive.ietf.org/arch/msg/add/wXuntcoAacXa4MWbgFRPhq-tVdg/

Boulder support may help make this encrypted DNS upgrade more accessible.

[nipil]

I see this as a very powerful solution against DNS hijacking cases.
Of course, it is only useful in situations where there is no need for a "user-friendly" entry point name.
But that is often the case for infrastructure, like @HLFH said about KVM switchs, i'm thinking routers, vpn gateways, etc.

[franklouwers]

To add to what @maertsen said: DDR has now been published as a full-blown RFC (RFC9462 - https://datatracker.ietf.org/doc/html/rfc9462) and requires IPs to be in the certificate.

It will auto-upgrade plain-unencrypted-dns to DoH when implemented. Can we please move forward with this?