Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
draft-ietf-acme-ip-08

[Ballot comment]
I had initially balloted DISCUSS, and, after discussions with the authors / WG am changing to No Objection.

I must admit I have a visceral dislike of this - making IP address certificates faster / easier / more automated to obtain them **feels**  like a bad outcome -- intellectually I understand that IP address certs already exist, and that standardizing the protocol is likely a good thing -- but it still makes me uncomfortable.

"This makes me twitch" is, however, not a reasonable criteria for a DISCUSS or blocking a document, and so I'm balloting No Objection.

I'd spent a while writing up an "Abstain" position (in the "I oppose this document but understand that others differ and am not going to stand in the way of the others." sense), but that simply felt like a non-blocking, passive-aggressive version of DISCUSS, so am settling on NoObjection...

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

[Ballot comment]
The author acknowledged that the following change will be done, so I cleared my DISCUSS:

Section 3 of RFC 6066 says:
  "HostName" contains the fully qualified DNS hostname of the server,
  as understood by the client.  The hostname is represented as a byte
  string using ASCII encoding without a trailing dot.

However your example shows in Section 6:

  For the "tls-alpn-01" challenge the subjectAltName extension in the
  validation certificate MUST contain a single iPAddress that matches
  the address being validated.  As [RFC6066] does not permit IP
  addresses to be used in the SNI extension HostName field the server
  MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596]
  reverse mapping of the IP address as the HostName field value instead
  of the IP address string representation itself.  For example if the
  IP address being validated is 2001:db8::1 the SNI HostName field
  should contain "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d
  .0.1.0.0.2.ip6.arpa.".

I.e. there is a trailing dot after “arpa”. Is the example wrong or am I missing something?

[Ballot comment]

Thanks for the work you put into specifying this mechanism. The only
comments I have are editorial.

---------------------------------------------------------------------------

§1:

>  In order to allow validation of
>  IPv4 and IPv6 identifiers for inclusion in X.509 certificates this
>  document specifies how challenges defined in the original ACME
>  specification and the TLS-ALPN extension specification
>  [I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers.`


Nit: "...certificates, this..."

---------------------------------------------------------------------------

§3:

>  If a ACME server wishes to
>  request proof that a user controls a IPv4 or IPv6 address it MUST
>  create an authorization with the identifier type "ip".

Nit: "...an ACME..."

Nit: "...address, it..."

---------------------------------------------------------------------------

§4:

>  To use IP identifiers with these
>  challenges their initial DNS resolution step MUST be skipped and the
>  IP address used for validation MUST be the value of the identifier.

Nit: "...challenges, their..."

Nit: "...skipped, and..."

---------------------------------------------------------------------------

§5:

>  For the "http-01" challenge the Host header MUST be set to the IP
>  address being used for validation per [RFC7230].

Nit: "...challenge, the..."

Nit: "...Host header field..."

---------------------------------------------------------------------------

§6:

>  For the "tls-alpn-01" challenge the subjectAltName extension in the
>  validation certificate MUST contain a single iPAddress that matches
>  the address being validated.

Nit: "...challenge, the subjectAltName..."

>  As [RFC6066] does not permit IP
>  addresses to be used in the SNI extension HostName field the server

Nit: "...HostName field, the server...."

>  For example if the
>  IP address being validated is 2001:db8::1 the SNI HostName field

Nit: "For example, if the..."

Nit: "...2001:db8::1, the SNI..."

---------------------------------------------------------------------------

§9.1:

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

Nit: "For example, if the CA..."

Nit: "...delegation periods, they may..."

[Ballot comment]
Section 7

There's perhaps some "action at a distance" going on here, in that we
try to apply normative requirements on unrelated things.  Perhaps it's
safer to just say "this document does not define any usage of the
'dns-01' challenge to validate IP addresses.  But if we can definitively
rule out any future use, then it doesn't really matter.

Section 9

Is there anything to say about issuing certificates for
non-publicly-routable IP addresses in terms of ensuring that the ACME
server and client are in the same administrative domain [and enforcing
that by network topology]?

[Ballot comment]
Short and useful document: thank you for writing it.

No need to reply to my two questions, but, I would appreciate your answers:
1) why using a tag "ip" rather than "address" ?
2) unsure whether it is doable, but, why only allowing /32 or /128 addresses? A server can listen to a /64 (for some specific applications), so, requesting a /64 via ACME would be useful (challenge could be done via a random address out of this /64 for example)

Regards

-éric

[Ballot discuss]
Thank you for this document.

I have a trivial thing I would like to discuss before recommending approval of this document:

Section 3 of RFC 6066 says:
  "HostName" contains the fully qualified DNS hostname of the server,
  as understood by the client.  The hostname is represented as a byte
  string using ASCII encoding without a trailing dot.

However your example shows in Section 6:

  For the "tls-alpn-01" challenge the subjectAltName extension in the
  validation certificate MUST contain a single iPAddress that matches
  the address being validated.  As [RFC6066] does not permit IP
  addresses to be used in the SNI extension HostName field the server
  MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596]
  reverse mapping of the IP address as the HostName field value instead
  of the IP address string representation itself.  For example if the
  IP address being validated is 2001:db8::1 the SNI HostName field
  should contain "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d
  .0.1.0.0.2.ip6.arpa.".

I.e. there is a trailing dot after “arpa”. Is the example wrong or am I missing something?

[Ballot comment]
I have only editorial comments below.  No response is needed — please just consider incorporating these, as I think they’ll help make the document clearer.

— Introduction —

  The Automatic Certificate Management Environment (ACME) [RFC8555]
  only defines challenges for validating control of DNS host name
  identifiers which limits its use to being used for issuing
  certificates for DNS identifiers.

This needs a comma before “which”.

— Section 2 —
Please use the new BCP 14 boilerplate and references (see RFC 8174).

— Section 3 —

  [RFC8555] only defines the identifier type "dns" which is used to
  refer to fully qualified domain names.

Similarly: needs a comma before “which”.

— Section 4 —

  IP identifiers MAY be used with the existing "http-01" and "tls-alpn-
  01" challenges from [RFC8555] Section 8.3 and
  [I-D.ietf-acme-tls-alpn] Section 3 respectively.

This is OK as it is, so take this or leave it as you will, but to my eyes the citations are needlessly separated from their anchors.  I would re-order it this way:

NEW
  IP identifiers MAY be used with the existing challenges
  "http-01" (see Section 8.3 of [RFC8555]) and "tls-alpn-01"
  (see Section 3 of [I-D.ietf-acme-tls-alpn]).
END

— Section 5 —

  The textual form of
  this address MUST be those defined in [RFC1123] Section 2.1 for IPv4
  and in [RFC5952] Section 4 for IPv6.

The subject is singular, so “those” doesn’t work.  An easy fix is to use “as defined”.

— Section 6 —

  For the "tls-alpn-01" challenge the subjectAltName extension in the
  validation certificate MUST contain a single iPAddress which matches
  the address being validated.

This needs “which” changed to “that”, to make it a restrictive clause.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-acme-ip-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ACME Identifier Types registry on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a single, new registration is to be made as follows:

Label: ip
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the ACME Validation Methods registry also on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

two, new registrations are to be made as follows:

Label: http-01
Identifier-Type: ip
ACME: Y
Reference: [ RFC-to-be ]

Label: tls-alpn-01
Identifier-Type: ip
ACME: Y
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will also initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-06-12):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, draft-ietf-acme-ip@ietf.org, Daniel McCarney , acme@ietf.org, cpu@letsencrypt.org, acme-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ACME IP Identifier Validation Extension) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'ACME IP
Identifier Validation Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-06-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-ip/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ballot/


No IPR declarations have been submitted directly on this I-D.

# Technical Summary

The ACME-IP draft extends the Automatic Certificate Management Environment
(ACME) with support for IP address type identifiers in addition to DNS type
identifiers. The draft additionally specifies how the existing ACME challenge
types (HTTP-01 and DNS-01) and the ACME-TLS-ALPN challenge type (TLS-ALPN-01)
interact with IP address identifiers.

# Working Group Summary

The description of using tls-alpn-01 for IP identifiers was fixed to respect RFC
6066's restriction on IP addresses in SNI by defining the ip-addr.arpa format to
use instead.

Earlier versions of the draft included a reverse-DNS challenge type. Within the
working group there were concerns raised about the accuracy of the reverse DNS
zone information that this challenge type relied on. A decision was made to
remove this challenge type from the draft to allow forward progress on the
remaining uncontroversial parts of the draft.

# Document Quality

The document is short and concise. The interaction between the existing challenge
types interact this new identifier type is well specified. I am not aware of any
existing implementations but at least one ACME server operator (Let's Encrypt)
intends to implement the draft in a test capacity (with the Pebble ACME server)
in the near future.

# Personnel

The document shepard is Daniel McCarney. The responsible area director is Eric
Rescorla.

# IRTF Note

Not applicable

# IESG Note

Not applicable

# IANA Note

There are two IANA considerations in Section 5. Both the "ACME Identifier Types"
table as well as the "ACME Validation Methods" table require updates.