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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 01 Oct 2019 08:25:31 -0700

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.

---

From: Roland Shoemaker <[email-masked]>
Date: Tue, 1 Oct 2019 10:10:10 -0700

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 <[email-masked]> wrote:
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 1 Oct 2019 14:27:40 -0400

> 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 mode…

I used 192.0.2.10 instead of something in the RFC1918 range to imply
that it was a publicly routed address, but I realize didn't actually
state that.

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

Yup, I've read 8555, but somehow it feels much more scary to have this
happen for IP addresses than for DNS names -- some of this might just
be me being triggered by expectations that addressed get reused (e.g
DHCP), and that e.g someone on the IETF meeting network could iterate
over all addresses, getting certificates for all of the space...

This still *feels* dangerous to me...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 1 Oct 2019 17:09:00 -0400

On Tue, Oct 1, 2019 at 2:28 PM Warren Kumari <[email-masked]> wrote:

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

What are the things you might be looking for to address the concern here?

The trouble with the scenario you've described basically requires one of
two things:
- Attackers to be proximate on the 'local' network of the validation target
(e.g. ARP poisoning)
- Attackers being able to control or influence routing tables as seen by
the issuing CA (e.g. BGP poisoning)

As Roland mentioned, both of these scenarios are no different than
dNSName-bearing certificates. dNSName suffers from issues such as DNS
spoofing/fragmentation, as we've seen. However, once the DNS has been
translated to an IP by the authoritative server, both scenarios you
describe here - ARP spoofing and BGP poisoning - are just as viable to
asserting possession of the domain name as they are the iPAddress.

It seems that the concern you've expressed here is slightly different than
the one you initially raised on the DISCUSS, and that's a question about
certificate lifetimes, and how long the assertion between a key and a
subjectAltName should be reasonably expected to be valid. The presumption
here is that domain names are "long-lived" in some form (e.g. with their
annual renewal), while iPAddresses are "short-lived" (e.g. due to DHCP
dispatching from pools). Is that a fair expression of the unease you're
expressing?

In practice, I think the concern you're expressing for IP addresses is
actually common for dNSNames too, as discussed on the topic of BygoneSSL (
https://insecure.design ), and that the solutions are largely not in the
validation space, but in defining meaningful and sensible profiles. In this
respect, an ACME method to support such iPAddress-bearing certificates
helps the problem, more than it worsens the problem, by providing coherent
and consistent APIs to facilitate shorter certificate lifetimes and clearer
management of those certificates.

Regardless of the position taken with respect to this draft document, such
certificates exist today, are recognized by major Root Stores, and
meaningfully help improve security of important services (such as DoH/DoT
to the resolver). So, hopefully that suggests it's a net-good to
standardize an approach that might be usable, in future policies, to only
permit such IP-bearing certificates iff constraints are met, such as
reduced lifetimes, automated issuance, etc.

Does that help put you at ease, with respect to this document?

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 1 Oct 2019 14:20:24 -0700

It's important to note that automated validation of IP addresses for 
certificates is already a part of the Web PKI, but is not standardized. 
This protocol will standardize it, which I believe will make  overall 
validation of IP addresses more secure, within the threat model that 
Roland described.

We could attempt to ban automated validation of IP address certificates, 
or ban IP address certificates entirely, but that wanders into the realm 
of policy rather than standards, and would be better suited to browser 
root programs IMO.

Overall, given the tradeoffs, I think it is better to have a 
standardized method of IP address validation than to have none.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 1 Oct 2019 17:25:25 -0400

On Tue, Oct 1, 2019 at 5:09 PM Ryan Sleevi <[email-masked]> wrote:
> The trouble with the scenario you've described basically requires one of two things:
> - Attackers to be proximate on the 'local' network of the validation target (e.g. ARP poisoning)
> - Attackers being able to control or influence routing tables as seen by the issuing CA (e.g. BGP poisoning)
>
> As Roland mentioned, both of these scenarios are no different than dNSName-bearing certificates. dNSName suffers from issues such as DNS spoofing/fragmentation, as we've seen. However, once the DNS has been translated to an IP by the authoritative server, both scenarios you describe here - ARP spoofing and BGP poisoning - are just as viable to asserting possession of the domain name as they are the iPAddress.
>

Yup, you are right -- it does end up being the same -- and yet,
somehow it still *feels* wrong...

>
> It seems that the concern you've expressed here is slightly different than the one you initially raised on the DISCUSS, and that's a question about certificate lifetimes, and how long the assertion between a key and a subjectAltName should be reasonably expected to be valid. The presumption here is that domain names are "long-lived" in some form (e.g. with their annual renewal), while iPAddresses are "short-lived" (e.g. due to DHCP dispatching from pools). Is that a fair expression of the unease you're expressing?
>

Yes, I *think* so, but I still have a gut "I really don't like this"
reaction -- and, annoyingly, I cannot figure out what is triggering
this...  Whatever the case, I understand that this is just my personal
hangup, and "Ugh, this makes me twitch" is not actually one of the
DISCUSS criteria -- and so I will either change my position to
"Abstain" (which is non-blocking) or "No Objection".

> In practice, I think the concern you're expressing for IP addresses is actually common for dNSNames too, as discussed on the topic of BygoneSSL ( https://insecure.design ), and that the solutions are largely not in the validation space, but in defining meaningful and sensible profiles. In this respect, an ACME method to support such iPAddress-bearing certificates helps the problem, more than it worsens the problem, by providing coherent and consistent APIs to facilitate shorter certificate lifetimes and clearer management of those certificates.
>
> Regardless of the position taken with respect to this draft document, such certificates exist today, are recognized by major Root Stores, and meaningfully help improve security of important services (such as DoH/DoT to the resolver). So, hopefully that suggests it's a net-good to standardize an approach that might be usable, in future policies, to only permit such IP-bearing certificates iff constraints are met, such as reduced lifetimes, automated issuance, etc.
>

Only kinda, but I do acknowledge that this is my issue, not that of
the document... I'll change to either Abstain ( in the "I oppose this
document but understand that others differ and am not going to stand
in the way of the others.") or "No Objection".

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 1 Oct 2019 17:44:41 -0400

> validation of IP addresses more secure, within the threat model that

ACME is sufficiently useful that I think it will cause the
proliferation of IP certificates, which to me seems like a bad outcome
-- but, as I realized above, this is my own personal view / bias, and
so I will be removing the DISCUSS.

> of policy rather than standards, and would be better suited to browser

Yeah - *to me* that seems like that would be a grand outcome...

> standardized method of IP address validation than to have none.

True, but making something "dangerous" easier and faster to do doesn't
necessarily seem like a win. Shooting myself in the foot used to
require checking the bore, pouring in powder, stuffing in some
wadding, shoving a ball down the muzzle, tamping everything down,
removing the rod, clearing a vent hole, adding powder to a pan, and
finally pointing it at my foot  - now, with automation I can remove
both feet in a hundreth of the time... (Why, yes, I have just been
watching a documentary on the Prussian / Danish war, what makes you
ask?...)

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 1 Oct 2019 18:07:31 -0400

> "Abstain" (which is non-blocking) or "No Objection".

... and I've changed my position to NoObjection -- sorry for the
drama, and thanks to all for helping me work though my IP address cert
neurosis...  :-)

W

---

From: Alan Doherty <[email-masked]>
Date: Wed, 02 Oct 2019 00:29:00 +0100

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

>please help me understand / convince me I'm missing something.

imho non event

>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 ;)