Cyclic dependency in trust

[bwesterb]

Should the CA trust the WebPKI to authenticate the MPIC service?

[birgelee]

I know this is ugly, but in the end of ensuring a clean implementation, I think a standard HTTPS connection simplifies things a lot. We could use some SHOULD language to say something like:

To avoid dependence on the webPKI, CAs deploying MPIC APIs SHOULD authenticate MPIC API endpoints using self-signed certificates or private trust anchors. MPIC API endpoints MUST be authenticated and traffic to an MPIC API endpoint MUST NOT be sent in plaintext.

IMO ensuring endpoint authentication is more important than the cyclic trust issue.

[SulemanAhmadd]

If we let the MPIC service sign it responses, do we still need a certificate for the MPIC endpoint? I wonder if CT logs also follow the same signed responses trust model. Only using signed responses though means we are comfortable with plaintext requests.

Also, there is a notion of whether the same authentication requirements apply for CA -> MPIC service and internally for MPIC service for contacting different perspectives.

[bwesterb]

If the attacker can manipulate the communication between CA and MPIC service, then signing the response is not enough. A simple example is the following. The attacker might change the domain name of the request to an attacker controlled domain name. If the response doesn't contain the domain name, then the CA might be convinced of domain control where none is present.

[SulemanAhmadd]

Right, but if the MPIC service signs over the request + response attributes then it can provide integrity of what was received and the outcome of MPIC process, to the client. Would that be sufficient?

[gcimaszewski]

From the docs, it looks like Cloudflare's Multipath DCV API does not return the exact URL/domain name paths that were validated (although it does gives the details of the CAA records). For a Cloudflare-like spec without authentication on the requests from CA to MPIC, the attack that @bwesterb described is likely feasible.
The current Open MPIC spec does return the full parameters used for the challenge queries in the validation-details field within the ValidationResponse type. For this case, a signature on the response will allow the CA to check that the MPIC service received the correct validation parameters. I agree with @birgelee that simply designating HTTPS would take care of both problems. AWS only allows HTTPS endpoints for its API services anyway.

[birgelee]

My high level thought is whether or not we have the signing service, the API must be run over HTTPS. I think this should be specified in the RFC.

I also agree that @bwesterb 's attack is viable if the API does not echo back the request in its response. If it does, I think this attack is mitigated.

I would put in a recommendation for echoing API call parameters in the response as not only does it mitigate this attack, but it makes a self-contained log object that does not need to be cross joined with the original requests. I know this sounds somewhat silly, but having done a good amount of analysis on Let's Encrypt logs, log lines that only make sense in context (i.e., response 1234 needs to be analyzed with request 1234 to know what domain was being checked) are a huge hassle in post analysis. I feel from an audit standpoint and an implementation simplicity standpoint, just echoing parameters improves the usability of the API.

[bwesterb]

Echoing will work for this particular attack if the client also checks that the request in the response matches the origin request. These are the kind of things that clients tend to forget.

My high level thought is whether or not we have the signing service, the API must be run over HTTPS. I think this should be specified in the RFC.

I agree. Let's lean as much on TLS as possible for transport security and not try to reinvent or complicate things too much.

Having an audit trail is a more convincing argument for echoing.

[SulemanAhmadd]

I am not sure how self-signed certs will provide us meaningful value on top of signed service responses (based on request+response data). Clients (CA) would have to verify the signature anyways. Confidentiality is not a concern given current requirements. We should consider ease of service deployment / management alongside. Lets aim to get more feedback on this at IETF.

On logging, though a separate issue, I agree on that. That one can be a MUST.

[TheEnbyperor]

@SulemanAhmadd see my comment in #6 on why TLS alone is likely not sufficient.