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

[Alan Doherty <[e-mail]>]

At 16:25 01/10/2019  Tuesday, Warren Kumari via Datatracker wrote:
trimmed

>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.

imho non event


>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.

same issue with all names/certs
if host 192.0.2.10   was using the cert https://very-secure-pos.webcafe.com
you equally by stealing the ip could get a cert for same name and get same ability to impersonate (though why public ips viable on a cafe wifi is a bit worysome)

the securing of ips from theft is not really relevant as once stolen all impersonation possible whether cert is name or ip based

(in the scenario above acme would be a poorer choice than long duration self signed cert and cert pinning on the limited client side)

acme and any trusted root cert is only sensible for those wanting to verify identity to wide public audience (where key verification by other means impossible/unfeasible) 

or just obviously not having any equipment on the same network as untrusted customers (most aps capable of multiple ssids/vlans etc) so wifi card readers shouldn't be talking via same network 

for myself the only utility in ip verification in acme is finally being able to add https://ip to the san certs already on my hosts so visitors don't click through accept prompts before getting the http redirect to the correct name ;)