Any update on GETS -> POSTs conversation

[rmbolger]

Continuing the discussion from ACME breaking change: Most GETs become POSTs:

@jsha

During a final round of review at IETF, ACME received some feedback that is likely to lead to a breaking change in how ACME handles GETs. Please read my summary for details:

https://mailarchive.ietf.org/arch/msg/acme/sotffSQ0OWV-qQJodLwWYWcEVKI

What this means for ACME client developers: At some point, assuming this change is made to the ACME spec, Let’s Encrypt will make available a new ACME endpoint conforming to the new version, which will be incompatible with both ACMEv1 and ACMEv2. The amount of work involved in changing most clients should be relatively small. Clients will need to change GET requests into signed POST requests.

Right now our recommendation for client developers is: If you are working on ACMEv2 implementation, it is probably better to wait for this upcoming spec change, unless you urgently need wildcard support. Please keep an eye on the ACME mailing list.

The ACMEv2 endpoint will continue to be available. We’ll announce a sunset date after we make the ACMEv3 endpoint available (again, assuming that the IETF ACME WG proceeds with the change).

Just curious if there is any news on this topic?

[cpu]

@rmbolger

Just curious if there is any news on this topic?

We're going to be posting an API announcement in the next day or so.

In the meantime here's a quick summary of my understanding of things (subject to change!):

1. The POST-as-GET change met consensus and was merged into the draft specification yesterday. There hasn't been a new numbered draft cut yet but I expect that will happen soon in order to enter another last-call. - draft-ietf-acme-acme-15 captures this change.
2. Pebble's support for mandatory POST-as-GET was merged today and you can begin implementing client support using Pebble with the -strict flag.
3. I filed an issue to implement optional POST-as-GET for Boulder. "Optional" meaning we'll handle POST-as-GET requests to resources but also continue to allow unauthenticated GET requests to the same resources for some time
4. We'll pick a date in the future based on the state of the ecosystem to disable unauthenticated GET requests to resources for the V2 API. This will bring Boulder in line with Pebble's -strict implementation.

None of this will affect the legacy V1 API. Earlier discussion included the idea we might implement a "V3" API for this change but I believe current consensus internally is leaning towards a flag day with the V2 API. I expect we'll make a final decision about this in the next day or two ahead of a formal API announcement.

I hope that summary helps! Overall I'm sorry about this late breaking change. It's challenging participating in standards work and I'm very sympathetic to the client developers that have to jump into action to address this in their clients.

[schoen]

@cpu

but I believe current consensus internally is leaning towards a flag day with the V2 API.

I think this is going to lead to a lot of broken wildcard renewals because we have a lot of Certbot users who don't have regular client upgrades (which you can see in the server-side client statistics). I would still advocate for the v3 idea as originally suggested.

[cpu]

@schoen

I think this is going to lead to a lot of broken wildcard renewals because we have a lot of Certbot users who don’t have regular client upgrades

These users would experience the same breakage when the V2 API was removed in favour of V3. If we schedule the V2 API flag day with this difficulty in mind I don't think its significantly worse.

[cpu]

@rmbolger

Just curious if there is any news on this topic?

We've posted our API announcement outlining the plan for POST-as-GET support & deprecation of unauthenticated GETs for ACME v2.

@cpu

We’ll pick a date in the future based on the state of the ecosystem to disable unauthenticated GET requests to resources for the V2 API.

We're targeting November 1st, 2019 for this.

[rmbolger]

Thanks for the update, @cpu. So it sounds like the timeline for client devs adopting POST-as-GET (PaG) support should look something like this.

• Today
  • Start working on a branch of your client that transitions to PaG using Pebble as the test server
• Date X when Staging supports PaG
  • Verify branch works properly against staging.
  • (Optional) Release client that uses PaG only against staging.
• Date Y when Production supports PaG
  • Release updated client that defaults to PaG
• November 1, 2019
  • Relax because users who are up to date shouldn’t have any issues with the disabling of unauthenticated GETs
  • Users who haven’t upgraded to the release from Date Y or later will break.

[cpu]

This client implementation plan sounds sensible to me. I’d estimate that “Date X” is likely to be in the next week or two, with Date Y following a week afterwards.

[rmbolger]

Also just to clarify, do I have this right? The only resources that will continue to be available without PaG after November 1, 2019 are:

• Directory
  • Forever GET’able
• newNonce
  • Preferably HEAD, but also GET’able
• Certificates
  • Though this is a Let’s Encrypt specific implementation decision based on the “MAY allow” phrasing in Section 6.3. Other ACME servers may choose not to allow it.

[cpu]

@rmbolger

The only resources that will continue to be available without PaG after November 1, 2019 are:

• Directory
  • Forever GET’able
• newNonce
  • Preferably HEAD, but also GET’able

Both correct

@rmbolger

Certificates

• Though this is a Let’s Encrypt specific implementation decision based on the “MAY allow” phrasing in Section 6.3. Other ACME servers may choose not to allow it.

I need to verify our plans here with @jsha and @roland. I believe our intention is to only suport POST-as-GET to certificates. The MAY allow you're referring to was recently removed in the working copy of the draft.

[jsha]

@cpu

I need to verify our plans here with @jsha and @roland. I believe our intention is to only suport POST-as-GET to certificates. The MAY allow you’re referring to was recently removed in the working copy of the draft .

Yep, that's correct. We'll treat certificates the same way we treat other resources: GETtable for now, but POST-as-GET in the future, to match the latest spec (draft-16).