Warren Kumari has entered the following ballot position for draft-ietf-acme-ip-07: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is either a huge issue, or a complete non-event -- I'm not sure which - please help me understand / convince me I'm missing something. Contrived, but simple example scenario: My local coffeeshop runs their Point of Sale (POS) system on 192.0.2.10. They have a certificate for this (e.g from LE), and all of their credit card machines contact the POS system using https://192.0.2.10. I now visit the coffee shop, and using e.g ARP spoofing grab 192.0.2.10. I then use ACME to request and get a cert for 192.0.2.10. I now fire up a webserver, the credit card machines happily connect to me, I present a valid cert, and they send me those sweet, sweet credit card numbers. I get that this isn't really an issue with ACME itself, but rather A: the existence of IP based certificates, and B: the fact that the ability to "control" an IP is more easily under an attackers control than the ability to "control" a useful domain name. As another exmaple, I could construct scenarios where I use BGP route hijacking to control an address remotely, without having to visit the victim network. The Security Considerations section *does* say: "The CA may wish to perform additional checks not specified in this document. For example if the CA believes an IP identifier belongs to a ISP or cloud service provider with short delegation periods they may wish to impose additional restrictions on certificates requested for that identifier." Again, I understand that ACME is "just" the protocol / means to automate this, but it seems that this is a sufficiently dangerous thing to be doing that having it more automated is a bad idea. Please don't misunderstand, I really like ACME - it's made my life much better, but its power / convenience might be dangerous here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you - this document is clear, understandable and readable. Also, thank you to Joel and Tim for their OpsDir reviews. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
