What is current industry-standard support of CAA iodef?

As I said in the How to test CAA & iodef notification functionality thread, Let's Encrypt doesn't send iodef notifications if a CAA record blocks issuance. There have been a couple issues in Boulder discussing doing so (#1248, #2580), which seem to be closed as something that isn't likely to happen in the near future.

But of course what matters isn't just what Let's Encrypt is doing, but what other CAs are doing too. (That is, if I allow Let's Encrypt to issue for my domains through CAA, the point is to stop unauthorized issuance from other CAs, and perhaps through iodef to get notified when someone is trying to do so.)

So, here's my question that I'm not sure how to research, so I'm posting here: Do "most" CAs send iodef notifications yet? Or is Let's Encrypt being like most of the CA industry in not yet supporting them?

The only information I've been able to find is this paper with data from late 2017, which says that they didn't receive any iodef notifications at all. But that was shortly after CAA was implemented, and perhaps the industry has started to include them?

2 Likes

I don't think there are much support for iodef, since the standard said "CAs can send report to the iodef url". At least, AlphaSSL (Globalsign), Sectigo, Amazon and Let's Encrypt are not sending. I know nothing about other CAs because I'm too poor to afford their full price certificates :rofl:

3 Likes

Thanks for your data points on my random question! It may be that the policies of the free providers are in some ways more important than those of the paid providers, because a free provider is probably more likely to be used by somebody doing something nefarious. (A paid provider certainly might be misused as well, particularly since they in theory might not want to turn away paying customers, but with most online payment systems there's more level of traceability for tracking something criminal than there is with free providers.)

2 Likes

Agreed. I'm actually more curious on how many transactional email Let's Encrypt might send if they enabled this feature. (Imagine the sudden drop in mail reputation :joy:)

2 Likes

Actually I suspect there are very few CAA-based issuance failures (certainly compared to the number of attempts done). In order to be a CAA failure I believe the challenges would need to have already succeeded, so you're talking about cases where (1) There's a CAA record at all, (2) the CAA record is one preventing Let's Encrypt, (3) there's an ACME client pointed to Let's Encrypt running somewhere that can fulfill challenges and yet is trying to renew unsuccessfully. (And to really be a recurring problem, add (4) nobody is noticing the failures thus allowing it to happen regularly.)

I suspect that in most cases where there's a failure preventing issuance that nobody seems to be noticing or correcting, the challenge would be failing as well (like, the domain name was moved to new hosting but nobody's turned off the old server yet). There was a recent post saying that 80% of HTTP-01 challenges fail. I think that case is much more likely than somebody changing their CAA record to no longer allow Let's Encrypt, but still have a client running that's trying. I'm sure the number of regular persistent CAA failures isn't zero, but limiting iodef notifications to, say, only happen once, or once per few months, would probably mean that they'd be sending iodef email significantly less often than the renewal notices they already send.

I don't have any real data though, and my guesses about the problems at the scale of this project have been proven wrong in the past, so I may yet be wrong once again. :slight_smile:

3 Likes