Subject: [Acme] I-D Action: draft-ietf-acme-ip-00.txt

From: [email-masked]
Date: Sun, 16 Jul 2017 16:24:49 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment of the IETF.

        Title           : ACME IP Identifier Validation Extension
        Author          : Roland Bracewell Shoemaker
	Filename        : draft-ietf-acme-ip-00.txt
	Pages           : 7
	Date            : 2017-07-16

Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for IP addresses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-ip/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-ip-00
https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Sun, 16 Jul 2017 16:29:20 -0700

There was some previous discussion about possibly using a slightly
simpler DNS based verification method on the list last time I posted
this as an individual submission. After reading through the CABF BRs for
IP validation I'm pretty sure the proposed solution (checking for a TXT
record in the reverse mapping zone) would not be considered BR compliant
so I've stuck with the originally proposed challenge.

On 07/16/2017 04:24 PM, [email-masked] wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 17 Jul 2017 08:14:51 +0300

> so I've stuck with the originally proposed challenge.

The relevant (proposed) text I could find says:

"[...] in a TXT record for the IP Address."

(This is from proposed "7 IP Address validation methods"[1]).

The only way I can make sense for having DNS records for the IP address
is the QNAME corresponding to the IP in reverse mapping. I don't see
the "or prepend a underscore label" or similar language for the method,
unlike the DNS domain validation, which has that sort of language.

So I interpret that for IP address of 192.0.2.1, the QNAME has to be:
"1.2.0.192.in-addr.arpa".

I guess the person to ask would Jeremy Rowley (he posted the latest
version of the text I could find to CABForum validation list).

Also, the relevant section for TLS-SNI in the "7 methods" says:

"[...] a Certificate on the IP Address [...]"

Whatever that actually means (I can come up with at least two different
interpretations, and both of these are probably wrong):

- The certificate has to certify the IP address.
- The connection has to ask for certificate on IP address, i.e., omit
  server_name.

... Both of these interpretations are technically problematic. And
neither is compatible with what the I-D text says.

[1] I presume CABForum wants to first get the "10 Domain Validation
methods" through, and then work on getting the "7 IP Address Validation
methods" passed.

-Ilari

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Sun, 16 Jul 2017 23:10:35 -0700

> version of the text I could find to CABForum validation list).

Could you clarify which proposed ballot or mailing list message you are
referencing. As far as I am aware the most recent CABF validation WG
product that discusses IP validation is from March and doesn't include
any reference to using TXT records
(https://cabforum.org/pipermail/public/2017-March/010214.html).

The most recent proposed language clarifies that any method which looks
up a DNS name for an IP using the reverse mapping then applies a 3.2.2.4
method is considered acceptable.

> neither is compatible with what the I-D text says.

My understanding of this, admittedly confusing, language simply means
the certificate presented by whatever server is running on the IP, not
that the cert needs to be for the IP or served blindly.

This language is in fact basically a copy/paste of the 3.2.2.4.10
language, for which tls-sni-02 was designed to be compatible with, that
is used for DNS names where "Authorization Domain Name" has been
replaced with "IP Address".

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 17 Jul 2017 10:39:10 +0300

> method is considered acceptable.

Oh, indeed the draft does it that way.

Also, multiple mailing lists and unlabeled versions makes following what
is the most recent quite confusing... Missed the later version that
dropped most of the methods.

> replaced with "IP Address".

I searched the archives of Validation WG.

The initial drafts of what became ballot 169 contained a method based
on text by J.C. Jones. This text covers TLS-SNI (even if I consider the
method bit dubious).

However, that definition got changed before the text became ballot,
specifically adding the "on the Authorization Domain Name" part. I can
not locate proper discussion of this change. Some text impiles it was
from F2F meeting, but minutes of that meeting don't seem to discuss the
matter.

Apparenty third interpretation of that is: Look up the IP address and
send some crap there. However, this interpretation seems to cause
trouble with method 6 (HTTP), which has the same language, with quite
clear implications.

Yeah, this is messy.

(And this confusing text is not the only problem with method 10, e.g.,
the method doesn't have the needed protections around use of random
values, seemingly allowing blatantly insecure validation... This
isn't fixed even in draft for ballot 190).

-Ilari

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 17 Jul 2017 17:03:12 -0700

This looks good! Nice work.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jul 2017 07:48:57 +0200

The biggest concern I have is the text regarding certificate lifetime
and the handling of the possibility that IP addresses are dynamically
allocated.  This seems a little weak and it leaves a lot to the CA to
manage.  Is there anything that can be done to gain a stronger
assertion that the allocation is (more) persistent?  An affirmation
from someone higher in the tree perhaps?

Some nits:

You definitely want to reference RFC 5952 here when it comes to IPv6 addresses.

Break the long line with the ip6.arpa example.

I would also recommend a shorter label, maybe _acme-ip.  You don't
want a very long name in case the base name is long (which is
relatively commonplace).

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jul 2017 07:59:07 +0000

> The biggest concern I have is the text regarding certificate lifetime and the
> handling of the possibility that IP addresses are dynamically allocated.  This
> seems a little weak and it leaves a lot to the CA to manage.  Is there anything
> that can be done to gain a stronger assertion that the allocation is (more)
> persistent?  An affirmation from someone higher in the tree perhaps?

That's interesting.

Who is "higher" in the tree?  IP space isn't hierarchical like DNS is it?

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 18 Jul 2017 18:45:57 -0700

> from someone higher in the tree perhaps?
I think ultimately this is a policy question and outside the scope of
ACME (except for pointing out that it's worth thinking about). If we
want a mechanism for owners of IP space to express the policy they'd
like CAs to apply to that space, it should probably look something like CAA.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jul 2017 16:39:24 +0200

> like CAs to apply to that space, it should probably look something like CAA.

In this case, I disagree.  With names, there is an expectation that
certificates can be issued for them.  This is not the default case for
IP addresses, so the defender is not naturally aware that they need to
defend this way.

I don't think that this needs to be onerous, but an explicit opt in
(as opposed to an opt out) would be preferable.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 19 Jul 2017 13:38:19 -0700

On 07/19/2017 07:39 AM, Martin Thomson wrote:
> IP addresses

Why do you say that issuance is disallowed by default for most IP
addresses? The CA/Browser Forum Baseline Requirements have
authentication methods that can be used to authenticate and issue for
any IP address.