Re: [Acme] Warren Kumari's Discuss on draft-ietf-acme-ip-07: (with DISCUSS and COMMENT)

[Roland Shoemaker <[e-mail]>]

Hey Warren,

Thanks for the review of this document. Overall I don’t find the suggested scenario particularly compelling in terms of indicating any security problems with the suggested document. The threat model defined in 8555 indicates that ACME is not able to mitigate scenarios where an attacker is able to demonstrate control of the validation target (whether this is via ARP poisoning on a local network in the suggest scenario or via DNS hijacking on the wider internet). Beyond that I don’t think this suggested scenario is that realistic. A public CA is unable to issue for internal private IP addresses, if the POS was using a certificate from an internal CA the attack might be viable, but only if that internal CA implemented ACME and allowed arbitrary user registrations which would be policy choices outside of the scope of this document.

The second scenario you suggest is also something covered by 8555, if the attacker is able to fully control the network, then they can control ACME. This is not just the case for IP validation, if an attacker is able to hijack BGP routes then they are able to complete validation for both IP and DNS identifiers (there is currently a handful of both academic and industry work happening to try and mitigate these issues) and is also not just the case for ACME, any CA that does network based control validation, automated or not, is susceptible to these kinds of attacks. 

Hope that helps clarify my thinking on the topic.
Roland

> On Oct 1, 2019, at 8:25 AM, Warren Kumari via Datatracker <[e-mail]> wrote:
> 
> 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.
> 
>