Boulder: Support CAA account key binding

[hlandau]

It would be nice if boulder supported a CAA record nominating an account key thumbprint via a parameter. This was envisioned by the CAA RFC.

Something like IN CAA 0 issue "letsencrypt.org; acme-ak=[base64url account key thumbprint]".

[rolandshoemaker]

:+1:, probably we'd also want to support either multiple thumbprints in a single record, or multiple records with single thumbprints.

[hlandau]

Yes, if you want multiple account keys you use multiple issue records.

I have a spec here: https://github.com/ietf-wg-acme/acme/compare/master...hlandauf:caa-ak

Ignore the 'sufficiency' part. I haven't submitted a PR for the spec yet since I'm ambivalent about it (because it changes the semantics of CAA from necessary to sufficient; though I can't actually think how this would be an issue), though it's moot anyway since AFAIK current CAB rules won't allow it.

I'll make a PR for the acme-ak part at some point.

[hlandau]

The CheckCAARecords VA RPC call will need to be changed to provide the necessary information.

What's the procedure for changing an RPC method signature?

[rolandshoemaker]

The Boulder dev wiki page gives some info on how to add/change RPCs.

The gist is you should add the changes in such a way that they are gated by a config bool so that when we deploy the changes previous behavior will be maintained but the new behavior is available. Once that deploy is done and every service supports the new RPC we can do another deploy to switch to it using the config bool and open an issue to remove the gating and old behavior.

[hlandau]

So on further inspection, it looks like CheckCAARecords isn't called anywhere except in tests, where having it on the interface is unnecessary since it's a *ValidationAuthorityImpl being used directly there.

As far as I can tell, removing CheckCAARecords as an RPC call can be done without consequence, without even a config flag, since nothing uses it via RPC. All CAA checking is actually done via UpdateValidations.

UpdateValidations will need to be changed, so I'll probably change it out for something which takes a request structure, which will at least make future expansion easier. Should probably considered desirable going forward, RPC-wise...

[rolandshoemaker]

Whoops, forgot to check that before giving you bad advice, my bad! Your new
plan sounds good, UpdateValidations has been a sore spot in the past so
some refactoring would be greatly appreciated. Eventually we are planning
on moving towards gRPC instead of our homebrew system but this won't happen
for a while.

On Tue, Feb 2, 2016 at 4:29 PM Hugo Landau [email protected] wrote:

So on further inspection, it looks like CheckCAARecords isn't called
anywhere except in tests, where having it on the interface is unnecessary
since it's a *ValidationAuthorityImpl being used directly there.

As far as I can tell, removing CheckCAARecords as an RPC call can be done
without consequence, without even a config flag, since nothing uses it via
RPC. All CAA checking is actually done via UpdateValidations.

UpdateValidations will need to be changed, so I'll probably change it out
for something which takes a request structure, which will at least make
future expansion easier. Should probably considered desirable going
forward, RPC-wise...

—
Reply to this email directly or view it on GitHub
https://github.com/letsencrypt/boulder/issues/1452#issuecomment-178909642
.

[noloader]

Support CAA account key binding... This was envisioned by the CAA RFC.

+1. This is great for a security diversification strategy. That is, a relying party/software consuming TLS certificates can check the CAA record and ensure the certificate is issued by the CA listed in the CAA. I actually use diversification strategies in my software. For more reading on security diversification strategies, see Peter Gutmann's Engineering Security.

The browsers despise software that utilizes the CAA record. They claim their objections are based on switching CAs can result in a DoS for the user. What the browsers don't say is _"Interception is a valid use case"_ in their security models, and pinning a CA based on a CAA records means interception does not usually work.

_"Interception is a valid use case"_ is why, for example, RFC 7469, Public Key Pinning with Overrides, has the overrides. It allows the bad guy to break the channel and perform the interception. The IETF should have rejected that broken standard.

NSA, GCHQ, LE and Bad Guys luvz Browsers and Web Security. Browser security is mostly a joke.

[hlandau]

I have a PR for this more or less ready once the current CAA PR is merged.

Browsers shouldn't, as I understand it, check CAA records. A CAA record authorizes issuance. It would be perfectly valid to set up a CAA record to get a certificate issued, and then tear down the record and use the certificate for its full validity period. What you probably want is DANE validation, not CAA.

I agree with you that the way that HPKP has been gimped is complete nonsense. I've previously written about this.

[nitmir]

This is a very nice idea. I think it could be nice to also have a tag to bind to specific challenge method line acme-chl=dns-01 for instance.

[sebastiannielsen]

Would also be nice if having a valid account-binding in an CAA record, should also constitute a pre-authorization for that account, which means that an conformant CA may issue certificates for any domain that returns such a binding, without challenging.

To comply with ACME spec, a new type of authorization could be created, called ”dns-02”, which will be considered authorized if a CAA record with a valid account binding and which the CA recongnizes as its own, is found at the time of the creation of the order.

This behaviour could be controlled with a flag, so this behaviour could be disabled if needed. Maybe bit 2 could be used for this, bit2 means then ”Don’t pre-authorize on basis on this record”.

Have also sent this to the person responsible for the draft.

[sebastiannielsen]

@noloader Interception IS a valid use case. One example is when a Corporate has a central virus scanner. This virus scanner terminates SSL, then Scans content, and reencrypts the traffic, this time with a certificate owned by the Corporation.
Basically, if you use someone else's network, its their network, not your network, and you might need to have your traffic x-rayed - like at the Airport - to prevent dangerous things to come aboard - Think "virtual bombs and knives" coming into their network. You still have the choice of not using such a network.

[pfigel]

Would also be nice if having a valid account-binding in an CAA record, should also constitute a pre-authorization for that account, which means that an conformant CA may issue certificates for any domain that returns such a binding, without challenging.

Unfortunately, such a validation mechanism is not permitted under Baseline Requirements, so adoption by publicly-trusted CAs such as Let's Encrypt wouldn't be possible. The Baseline Requirements ask for either a Random Value or a Request Token to be part of the validation procedure, both of which can only be used for either 30 days or one certificate request. A static DNS record referencing an ACME account/key would not fulfil this requirement.

I would suggest moving further discussion to the ACME WG mailing list.

[sebastiannielsen]

Wouldn't 3.2.2.4.11 allow such a validation method?

[pfigel]

I don't think 3.2.2.4.11 is still part of the Baseline Requirements? Either way, it's at least pending removal and some root programs (e.g. Mozilla) have explicitly banned it.

[sebastiannielsen]

Also the baseline program explicitly allows using a hash of SPKI (certificate public key) or CSR as request token, which can be static over a long time, which also means this could be used somewhat. Maybe this could be part of CAA specification in some way. They recommend appending a timestamp to the hash, but isn't explicitly required.

[pfigel]

Request Tokens are either single-use or limited to 30 days. Either way, this is the wrong venue for further discussion.

[rcombs]

I see that the spec branch mentioned earlier in this discussion had a PR, which has since been rejected (largely due to documentation positioning). Any reason this hasn't moved forward since?

[4a6f656c]

Boulder now supports (at least in staging, hopefully soon in production) the CAA record extensions for account URI and ACME method binding, as detailed in the draft-ietf-acme-caa RFC. This means that you can use account-uri and validation-methods CAA parameters to restrict issuance. Further details are in this announcement.

@jsha @cpu I suspect this issue can be closed.

[TheBlueMatt]

Looks like maybe this issue was closed prematurely? AFAICT, this change was never deployed and only exists in staging, per the announcement linked.

[rolandshoemaker]

This issue was for tracking CAA account key binding support in boulder, which is complete. Let's Encrypt hasn't deployed this functionality to production because of CABF/CAA specification issues which are on path to be resolved, but we aren't tracking that here.

The Let's Encrypt community forum is likely a better place to discuss this.