Subject: [Acme] Fwd: New Version Notification for draft-shoemaker-acme-ip-00.txt

From: Roland Shoemaker <[email-masked]>
Date: Mon, 27 Mar 2017 13:38:11 -0700

Probably of interesting to some people here, would love to hear your
thoughts.

-------- Forwarded Message --------
Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt
Date: Mon, 27 Mar 2017 13:30:19 -0700
From: [email-masked]
To: Roland Bracewell Shoemaker <[email-masked]>, Roland
Shoemaker <[email-masked]>

A new version of I-D, draft-shoemaker-acme-ip-00.txt
has been successfully submitted by Roland Bracewell Shoemaker and posted
to the
IETF repository.

Name:		draft-shoemaker-acme-ip
Revision:	00
Title:		ACME IP Identifier Validation Extension
Document date:	2017-03-27
Group:		Individual Submission
Pages:		6
URL:
https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt
Status:         https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/
Htmlized:       https://tools.ietf.org/html/draft-shoemaker-acme-ip-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00

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

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.

The IETF Secretariat

---

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Mar 2017 19:28:53 -0400

Thanks, Roland.  Interesting draft.

Couple of first reactions:

- Why use the target of the PTR instead of just provisioning the TXT record
directly in the reverse DNS.  (Is there some restriction in the spec for
reverse DNS that says it's only PTR?)  It seems like by using the PTR
target, your security analysis gets much more complicated.

- For the re-use of "http-01", you should probably specify the contents of
the Host header.  (Main ACME should probably clarify that for DNS, if it's
not clear already.)

On Mon, Mar 27, 2017 at 4:38 PM, Roland Shoemaker <[email-masked]>
wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Mon, 27 Mar 2017 17:30:58 -0700

On 03/27/2017 04:28 PM, Richard Barnes wrote:
> - Why use the target of the PTR instead of just provisioning the TXT
> record directly in the reverse DNS.  (Is there some restriction in the
> spec for reverse DNS that says it's only PTR?)  It seems like by using
> the PTR target, your security analysis gets much more complicated.
> 

The original reason for this was that I held the belief that there was
an RFC that set restrictions on the record types that should exist in
the reverse zones (i.e. PTR/CNAME/NS/SOA) only. After looking through
relevant documents for the last hour though I can't actually find
anything that states this and a number of example zones do seem to
contain other types, notably TXTs.

Based on this I think it does makes sense to remove the use of the PTR
target and just require the provisioning of a TXT record at the reverse
mapping node.

> - For the re-use of "http-01", you should probably specify the contents
> of the Host header.  (Main ACME should probably clarify that for DNS, if
> it's not clear already.)
> 

Good point.

> On Mon, Mar 27, 2017 at 4:38 PM, Roland Shoemaker
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     From: [email-masked] <mailto:[email-masked]>
>     To: Roland Bracewell Shoemaker <[email-masked]
>     <mailto:[email-masked]>>, Roland
>     Shoemaker <[email-masked] <mailto:[email-masked]>>
> 
> 
>     <https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt>
>     Status:       
>      https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/
>     <https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/>
>     Htmlized:     
>      https://tools.ietf.org/html/draft-shoemaker-acme-ip-00
>     <https://tools.ietf.org/html/draft-shoemaker-acme-ip-00>
>     Htmlized:
>     <https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00>
> 
> 
>     Abstract:
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>.
> 
>     The IETF Secretariat
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
> 
>

---

From: Alan Doherty <[email-masked]>
Date: Tue, 28 Mar 2017 13:04:22 +0100

At 00:28 28/03/2017  Tuesday, Richard Barnes wrote:
>Thanks, Roland.Â  Interesting draft.
>
>- Why use the target of the PTR instead of just provisioning the TXT record directly in the reverse DNS. Â (Is there some restriction in the spec for reverse DNS that says it's only PTR?) Â It seems like by using the PTR target, your security analysis gets much more complicated.

i can see sense here as getting an isp to point a customers ptrs at a set of names is easy
(getting many to put anything else in a in-addr.arpa zone is non-simple as many use horrible front ends with limited options)

as smaller customers have no direct control over ptr-zones but achieve control via isp (or cname as ptr to zone they can control) such as mine 106.238.120.193.ptr.narrowpoint.com

>- For the re-use of "http-01", you should probably specify the contents of the Host header. Â (Main ACME should probably clarify that for DNS, if it's not clear already.)

i would hope the host header would be the ip as its the ip being authenticated so a cert covering https://xxx.xxx.xxx.xxx can be genereated
(as personally id like to be able to add the ips to the san cert (even though the ip normally just serves an impolite error suggesting the 'bot-usually' try probing elsewhere ;)

>On Mon, Mar 27, 2017 at 4:38 PM, Roland Shoemaker <<mailto:[email-masked]>[email-masked]> wrote:
>From: <mailto:[email-masked]>[email-masked]
>To: Roland Bracewell Shoemaker <<mailto:[email-masked]>[email-masked]>, Roland
>Shoemaker <<mailto:[email-masked]>[email-masked]>
>
>
>Name:Â  Â  Â  Â  Â  Â draft-shoemaker-acme-ip
>Revision:Â  Â  Â  Â 00
>Title:Â  Â  Â  Â  Â  ACME IP Identifier Validation Extension
>Document date:Â  2017-03-27
>Group:Â  Â  Â  Â  Â  Individual Submission
>Pages:Â  Â  Â  Â  Â  6
>URL:
><https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt>https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt
>Status:Â  Â  Â  Â  Â <https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/>https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/
>Htmlized:Â  Â  Â  Â <https://tools.ietf.org/html/draft-shoemaker-acme-ip-00>https://tools.ietf.org/html/draft-shoemaker-acme-ip-00
>Htmlized:
><https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00>https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00
>
>
>Abstract:
>Â  Â This document specifies identifiers and challenges required to enable
>Â  Â the Automated Certificate Management Environment (ACME) to issue
>Â  Â certificates for IP addresses.
>
>
>
>
>until the htmlized version and diff are available at <http://tools.ietf.org>tools.ietf.org.
>
>The IETF Secretariat
>
><mailto:[email-masked]>[email-masked]

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 28 Mar 2017 11:08:38 -0700

> contain other types, notably TXTs.

I think you were probably thinking of https://tools.ietf.org/html/rfc3172:

   This domain is termed an "infrastructure domain", as its role is to
   support the operating infrastructure of the Internet.  In particular,
   the "arpa" domain is not to be used in the same manner (e.g., for
   naming hosts) as other generic Top Level Domains are commonly used.

I think Roland's approach is reasonable given the above constraint. Richard,
you mentioned this complicates the risk analysis. Could you go into more detail?

---

From: Jim Reid <[email-masked]>
Date: Tue, 28 Mar 2017 19:30:28 +0100

> On 28 Mar 2017, at 01:30, Roland Bracewell Shoemaker <[email-masked]> wrote:
> 

No such restriction exists. Any RRtype can appear in any zone/domain. The DNS protocol does not impose any constraints on which RRtypes can go where.

There are some corner cases arising from policy, not protocol, matters however. For example, a zone signed with DNSSEC-bis probably won't have NSEC3 or NSEC3PARAM records while one using DNSSEC-ter probably won't contain NSEC records.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Mar 2017 22:08:03 +0300

> target, your security analysis gets much more complicated.

Reading proposed IP validation rules in CABForum, using PTR target would
certainly qualify, whereas putting TXT record on the name probably does
not.

The proposed rules have nothing on DNS apart from PTR lookups.

(The current rules have "other equivalent method" clause.)

So my reading is, that one has to do the PTR lookup in order to remain
compliant with BRs after the proposed tighening of IP validation goes
through (I expect it to).

> the Host header.  (Main ACME should probably clarify that for DNS, if it's

Reading the proposed and current rules, the challenge is either invoked
on IP address itself, or on reverse-DNS lookup of it. So if you don't 
do rDNS lookup, then the validation is invoked on IP address itself,
which I think leads to empty Host-header.

TLS-SNI-02 would work as usual (the proposed rules explicitly list
method 10, which is what TLS-SNI-02 falls under). Existing rules don't
say anything (but again, equivalent method clause exists).

-Ilari

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Mar 2017 15:13:43 -0400

On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara <[email-masked]>
wrote:

> record
> of

Au contraire!

rbarnes$ nc -l 8080 >/dev/null &
rbarnes$ curl -v http://127.0.0.1:8080
* Rebuilt URL to: http://127.0.0.1:8080/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.51.0
> Accept: */*

Guess this is good evidence that we should document this :)

---

From: Niklas Keller <[email-masked]>
Date: Wed, 29 Mar 2017 06:34:25 +0000

>From RFC 2616:

A client MUST include a Host header field in all HTTP/1.1 request messages
. If the requested URI does not include an Internet host name for the
service being requested, then the Host header field MUST be given with an
empty value.

I guess an IP address is not considered an Internet host name and thus the
Host header must be empty.

Regards, Niklas

Richard Barnes <[email-masked]> schrieb am Di., 28. März 2017, 21:13:

> On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara <[email-masked]
> > wrote:
>

---

From: Alan Doherty <[email-masked]>
Date: Wed, 29 Mar 2017 13:01:44 +0100

all i know is if i browse to http://the-ip-of-my-site
i hit the vhost that matches the name the-ip-of-my-site
not the default vhost for 'empty hostname'

so i know that no http1.1 browser seen yet sends empty host header when browsing to an ip

(as the empty/unmatched host header vhost responds with a page offering http1.0 links to all the sites, and http1.0 compatible links to download http1.1 compatible clients (amazingly few browsers can be downloaded with a http1.0 client btw) (tested with ncsa mosaic v1 ish)

and gets extremely few hits ever

but the ip as name vhost sees hundreds of hits an hour from probes/bots/attackers and logs/redirects or blacklists them based on attack type seen

At 07:34 29/03/2017  Wednesday, Niklas Keller wrote:

>From RFC 2616:
>
>A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value.
>
>I guess an IP address is not considered an Internet host name and thus the Host header must be empty. 
>
>Regards, Niklas 
>
>Richard Barnes <[email-masked]> schrieb am Di., 28. MÃ¤rz 2017, 21:13:
>On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara <<mailto:[email-masked]>[email-masked]> wrote:
>> directly in the reverse DNS.Â  (Is there some restriction in the spec for
>> reverse DNS that says it's only PTR?)Â  It seems like by using the PTR
>> the Host header.Â  (Main ACME should probably clarify that for DNS, if it's
>> not clear already.)
>
>rbarnes$ curl -v <http://127.0.0.1:8080>http://127.0.0.1:8080
>* Rebuilt URL to: <http://127.0.0.1:8080/>http://127.0.0.1:8080/
>* Â  Trying 127.0.0.1...
>* TCP_NODELAY set
>> Host: <http://127.0.0.1:8080>127.0.0.1:8080
>> User-Agent: curl/7.51.0
>> Accept: */*
>>Â 
>
>Â

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 29 Mar 2017 17:11:31 +0300

> Host header must be empty.

Actually, RFC 2616 has been obsoleted in relevant parts by RFC 7230,
which says any kind of authority MUST be put into host (unless the
URL is absolute) and kinds of authority also include IPv4 address
literials, IP address literials (especially IPv6) and hostnames.

So by RFC 7230, IP addresses are put into host header.

-Ilari