Security measures during initial validation

[cpu]

Hi @LoSc, thanks for taking the time to evaluate ACME and Let's Encrypt. We appreciate it!

@LoSc

as part of a research project for an academic conference paper we are currently assessing security properties of various CAs during domain validation.

Please let us know when you have a draft of your paper

@LoSc

we didn’t observe countermeasures suited to mitigate such an attacker.

As you noted, your attacker/threat model corresponds to the ACME protocol's threat model for the "active attacker on the validation channel" case.

Knowing that, Section 10.2 of the ACME security considerations specifically says:

An active attacker on the validation channel can subvert the ACME process, by performing normal ACME transactions and providing a validation response for his own account key.

You are not seeing countermeasures because the security properties of ACME have never made any guarantees against protection for this attacker in the ACME threat model.

If you start with a different threat model than the one defined in the protocol you are investigating you will certainly find discrepancies. I would definitely encourage you to operate under the well defined threat model from the specification and be explicit when you are giving your adversary powers that are beyond those the protocol intends to address (as in this case).

@LoSc

HTTP-based validation should take place via HTTP S with the same DANE checks. HTTP should only be used if prior HTTP S validation failed (i.e. due to operational reasons) and there is no DANE-indication of HTTPS support.

I don't think this recommendation is practical. Focusing on just the HTTPS portion of your recommendation I have to note that the HTTP-01 challenge is required to use HTTP not HTTPS for the explicit reason mentioned in Section 8.3:

Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

There is also fairly substantial discussion of this in the ACME working group mailing list history. How does your suggestion interplay with the 'default SNI' attack that was the basis of requiring HTTP-01 operate on port :80 instead of :443? It seems at face value that recommending this would address one problem while re-introducing another.

@LoSc

These approaches prevent this attack for security aware domain owners while still maintaining compatibility with users not willing or able to deploy additional DNS records.

If users are not willing or able to deploy additional DNS records why would they be willing or able to deploy DANE? Oops! I misunderstood. You're intending this DANE approach be used by "security conscious users" while maintaining compatibility with users that don't want to/can't deploy additional DNS records. My apologies for misunderstanding.

For this case, would it be fair to say a simpler solution for security power users would be to deploy ACME-CAA records specifying validationmethods=dns-01 and pinning to a specific ACME account ID with a accounturi restriction? (note: this is of course presently only possible in the staging environment)

@LoSc

For these users, we share draft-12’s recommendation of performing requests (DNS/HTTP/TLS) from multiple vantage points to mitigate this attack.

Great! Glad to hear that your team agrees that the on-going work in this area will be helpful.

@LoSc

However, this change doesn’t address the man-in-the-middle vulnerability which causes TLS-ALPN to be affected as well.

That's correct. TLS-ALPN-01 wasn't meant to address this vulnerability because it is outside of the ACME threat model. The protocol acknowledges an active man-in-the-middle attacker on the validation channel is able to subvert the authorization process.

I hope that helps clarify our stance. Thanks again!