you probably know that recently there was an incident, where an attacker could issue a cert from LE to start a classic MITM attack, against a service that was also using LE see: https://notes.valdikss.org.ru/jabber.ru-mitm/ . A more restrictive CAA record could have prevented the attack but this shows how important this topic is.
As letsencrypt is the most popular and free CA these days I would really like to see "iodef" support of CAA records being supported by LE. Currently the iodef value is ignored so that in cases like the above mentioned the domain owner would not be noticed about abusive certificate requests reaching LE.
I saw a short discussion about this (Basic CAA iodef support?), there is was argued that sending mail is expensive and unreliable. I want to argue that LE sends out mail at least twice before a certificate expires. So sending mail can't be that expensive . Given also that "iodef" notices should not be sent out very often and if they are being sent out it is like a red alert notice, which should be tried to be sent out no matter what.
If you care about mail abuse with the diven iodef mail addresses, then I agree, there might be a point, domain owners could put any mail address there, but on the other sire this is the same issue for all other LE generated reminder mail for expiring certs.
What you could also support is http iodef reports:
The IODEF report is submitted as a web service request to the HTTP address specified using the protocol specified in [RFC6546].
But I think it is urgently required that you add some kind of iodef support so that hacking crimes like this can be noticed when they are being tried to be be committed.
While I certainly don't object to Let's Encrypt implementing iodef and I think they probably should get around to it, I'm not sure what kind of protection you think this would add for this kind of attacker. The iodef is mainly only useful when implemented by the CAs which you aren't using. If you're already using the account extensions for CAA for Let's Encrypt, then I suppose that getting an iodef notification from Let's Encrypt from someone else also using Let's Encrypt but for a different account would let you know that someone managed to intercept your traffic, but they didn't succeed in getting a cert and I'm not sure what action you could take about it. I'd be more worried about them intercepting the DNS requests and changing the CAA record on you, or intercepting the mail to the iodef address.
Using DNSSEC, and having your IP using RPKI and such, will do much more for you than Let's Encrypt implementing iodef will.
Adding to the above: For detecting unexpected certificate issuance, the proper tool for the job is certificate transparency monitoring. There are various tools out there* that can tell you when any CA issues a certificate for your domains and would also have enabled detection of the linked attack. CAA iodef on the other hand would not have detected this type of attack.
*There's a non-exhaustive list of such tools available online. You can also script your own solutions (I wrote some example python code a few years ago).
certificate transparency monitoring can help you detect when it is too late and someone was successfull with a certificate issuance. That does not show you when someone unsuccessfully tried to get an issuance, which is also important to know.
it is not a "protection" but it is a tool that can give you an important heads-up that someone is trying to tamper your TLS connections. And it is also useful for your own CA, of course, if your CAA record is provided with the accounturi attribute, then an issuance attempt from a different account uri at LE would trigger a iodef warning.
I didn't say that it was unimportant. I stated that certificate transparency is the better tool for the job, because it's universally applicable and more reliable. If an unauthorized certificate is detected you can still request revocation. It is far from perfect, but it's the best option we have with the current PKI system.
This assumes an incompetent attacker though: iodef alerts can simply be avoided by an attacker by checking CAA before commencing the attack. The attack you referenced would not have triggered iodef. Iodef is a useful tool to detect mistakes, misconfigurations and low-skilled/low-effort attacks.
To reiterate: I'm not against supporting this feature, I think it would be nice to have. However, I do understand why very few CAs choose to support it and I do not consider it a criticial safety improvement.
Now that we check CAA after a domain validation challenge has been successful, it’s easier for us to implement iodef without being a spam magnet like it was before.
Unfortunately, managing this email system is one of our largest expenses, especially from an "engineering time and effort" perspective. We constantly wish that we could stop sending renewal reminder emails for a variety of reasons, but they're too useful for us to stop. It's highly unlikely for us to add another automated email without investing in massive email infrastructure improvements first.
I don't fully agree with this conclusion. You're right that a more restrictive CAA record would have prevented the attack. In which case, what purpose would the iodef record serve? Sure, we might notify the domain operator that someone tried to issue for their domain, but we couldn't provide any useful information about the attempt. The attempt could be anywhere between an innocent typo, a minor misconfiguration of your own, or a nation-state actor. When you get an email in your inbox that says "Your CAA records prevented issuance of a cert for your domain" what action will you take with that email?
This is the fundamental issue with iodef records, and why Let's Encrypt hasn't implemented them so far. Either you're savvy enough with CAA to have set records that provide effective protection, and receiving an iodef notification email is unactionable and useless. Or you haven't set up CAA records and you'll never get a notification email at all. There's no situation in which receiving an iodef notification is actually useful and actionable.
well caa iodef have option to send incident report to a http post so some server : rfc8659 section 4.4 pointing https://www.rfc-editor.org/rfc/rfc6546
while I think nobody currently running reciever for it may able to used without sending a email:
I generally don't like when people make absolute statements like this because it implies that other people, who have a different views are doing something wrong or thinking wrong or whatever. Maybe you don't see a usefulness in iodef notifications, other people may definitely see that differently.
Apart from my personal point of view, why I think that iodef notifications are useful, I can point out another use case: some organization (take some university or whatever you want to think of) admin, who generally allows cert issuance only from one accounturi wants to get notified when some single host admin tries to get a cert issued for his own machine. I'm sure you will tell again that this is a bad idea and not a valid use case. Try to be more open to other people's views and needs.
I actually love this example, because you're right, I think this would be very useful! But I can't see it actually working:
we could provide the account ID which tried to issue, but that's just an opaque URL so it's not helpful to the admin trying to investigate.
we can't provide the email address associated with that account, because that's personally identifiable information and against our privacy policy.
we can't provide the IP address from which they tried to issue for the same reason.
So the email we send to the organization admin says "Someone tried to issue for foo.college.edu, and your CAA record's accounturi binding stopped them." What does the org admin do with this email? What investigation do they do? Where do they start?
You're right that notifying them is potentially more helpful than not notifying them -- if we don't notify them, they never even know that there's anything to investigate. It also could be annoying, if they're getting notified every time a freshman tries to spin up a webserver on the student network. So in my opinion it's not enough more helpful to be worth the implementation and maintenance effort.
as most caa is on tld+1 and likely gorven entire domain, I think what subdomain it requested be enough to call right person; and one passed challenge but blocked by CAA is still high risk message, because it's still in position to intercept the traffic and try other thing like sslstrip
looks like entire IODEF thing is kinda dead stendard: working group cloesd 2020, and I can't find any agent that do RID with v2 as 8727 requires: does BR forces to follow the protocal when we do act upon iodef record?
When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as
specified in RFC 8659, although they are not required to act on the contents of the iodef property
tag.
I would only need a minute to find the email address of the culprit to ask them what they were doing. (I admin a small on-prem cloud at a university.) Not that I would have to, because our CAA record lists all the free ACME services. (Why keep people from doing the right thing?) I only ever worried about someone hitting the rate limits and blocking issuance for the whole university, but the later added renewals limit removed that worry.
. Given also that "iodef" notices should not be sent out very often and if they are being sent out it is like a red alert notice, which should be tried to be sent out no matter what.