Subject: [Acme] Threat model for claiming domains

From: Tony Arcieri <[email-masked]>
Date: Mon, 1 Dec 2014 16:33:26 -0800

Is there a published threat model for claiming domains? I haven't been able
to find it, but I'd certainly like to read it!

If we simply accept a service running on the same IP that a given DNS name
points to, there seems ample opportunity to register certificates for
services colocated on the same IP.

-- 
Tony Arcieri

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Dec 2014 19:25:59 -0500

Hey Tony,

I just got around to thinking about this for a moment.  Obviously, our
baseline here should be whatever the CAs are doing today, since we have
empirical evidence that those methods are more or less OK.  I did a quick
and dirty empirical survey of the top few CAs this afternoon:

https://docs.google.com/a/ipv.sx/document/d/1KVKIS6abA2KL-yHvFsMql6U3qUjVhgO6p19Hzci0vQo/edit?usp=sharing

For the most part, they rely on sending an email to either the registered
WHOIS contact, or something like admin@domain.  GlobalSign supports
validation based on a DNS record or a <meta> tag in index.html.

With regard to your concern about services colocated on the same IP
(presumably for simpleHttps and DVSNI validation): This seems to mostly be
addressed by not allowing the ACME client to specify the port that the ACME
server connects to.  That means that the attacker has to control not only
something on the box, but the default port for HTTP or HTTPS.  If that's
not the case, normal routing based on the Host header or SNI should ensure
that the validation request goes to the right place.

Nonetheless, I agree that more analysis would be useful, across all the
validation methods.

--Richard

On Mon, Dec 1, 2014 at 7:33 PM, Tony Arcieri <[email-masked]> wrote:
>
> Is there a published threat model for claiming domains? I haven't been
> able to find it, but I'd certainly like to read it!
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Rob Stradling <[email-masked]>
Date: Mon, 22 Dec 2014 10:43:07 +0000

Hi Richard.  This pdf has some more details on Comodo's other domain 
validation methods...

https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf

On 20/12/14 00:25, Richard Barnes wrote:
> empirical evidence that those methods are more or less OK.  I did a
> quick and dirty empirical survey of the top few CAs this afternoon:
>
> For the most part, they rely on sending an email to either the
> registered WHOIS contact, or something like admin@domain.  GlobalSign
> supports validation based on a DNS record or a <meta> tag in index.html.
>
> (presumably for simpleHttps and DVSNI validation): This seems to mostly
> be addressed by not allowing the ACME client to specify the port that
> the ACME server connects to.  That means that the attacker has to
> control not only something on the box, but the default port for HTTP or
> HTTPS.  If that's not the case, normal routing based on the Host header
> or SNI should ensure that the validation request goes to the right place.
>
> On Mon, Dec 1, 2014 at 7:33 PM, Tony Arcieri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Is there a published threat model for claiming domains? I haven't
>     been able to find it, but I'd certainly like to read it!
>
>     If we simply accept a service running on the same IP that a given
>     DNS name points to, there seems ample opportunity to register
>     certificates for services colocated on the same IP.
>
>     --
>     Tony Arcieri
-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Dec 2014 09:29:23 -0500

Hey Rob,

Thanks for this.  The HTTP one looks more or less as I would have
expected.  We should probably tighten up the ACME one to look more like it.

With regard to the DNS validation:
1. Is there a reason you guys use CNAME instead of TXT?
2. W.r.t. using a subdomain vs. the name itself: When we wrote the current
ACME spec, the thinking was that it might be possible for an applicant to
provision a subdomain without being able to provision a record under the
name itself.  For example, with my Dreamhost hosting account, I can
register any records I want under "<md5>.dreamhosters.com", but I can't
provision under "dreamhosters.com".  Are you accounting for this risk
somehow?

I notice that there are mentions of an API in that document.  If you have
other API documentation you could share, that could be useful.  In
particular, it would make it easier to make ACME something that you guys
could transition to :)

--Richard

On Mon, Dec 22, 2014 at 5:43 AM, Rob Stradling <[email-masked]>
wrote:
>> https://docs.google.com/a/ipv.sx/document/d/1KVKIS6abA2KL-
>> yHvFsMql6U3qUjVhgO6p19Hzci0vQo/edit?usp=sharing
>>

---

From: Peter Bowen <[email-masked]>
Date: Mon, 22 Dec 2014 10:36:40 -0800

> particular, it would make it easier to make ACME something that you guys

It appears that the other API documentation is in the same directory:
https://secure.comodo.com/api/pdf/latest/

https://secure.comodo.com/api/pdf/latest/AutoApplySSL.pdf is the primary API.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 23 Dec 2014 12:29:39 +0000

> 1. Is there a reason you guys use CNAME instead of TXT?

Hi Richard.  I don't recall any particularly good reason for why we 
chose to use CNAME instead of TXT.  I think it was just a case of 
sticking with what we knew would work and with what our customers were 
more likely to already be familiar with.

> 2. W.r.t. using a subdomain vs. the name itself: When we wrote the
> current ACME spec, the thinking was that it might be possible for an
> applicant to provision a subdomain without being able to provision a
> record under the name itself.  For example, with my Dreamhost hosting
> account, I can register any records I want under "<md5>.dreamhosters.com
> <http://dreamhosters.com>", but I can't provision under
> "dreamhosters.com <http://dreamhosters.com>".  Are you accounting for
> this risk somehow?

I just started going through the signup process at www.dreamhost.com.  I 
see that it would be trivial to register the domain <md5>.dreamhosters.com.

IIUC, you're suggesting that there's a risk that Dreamhost might let you 
register a CNAME record for <md5>.dreamhosters.com that points to 
<sha1>.comodoca.com.
A colleague just said to me: "most shared hosts (like Dreamhost) 
designate that subdomain you request for webhosting and that it's 
incredibly unlikely (read: near-impossible) to get them to change their 
DNS for that to point anywhere other than their shared hosting servers."

BTW, the reason I came up with the idea of using CSR hashes was because 
we were trying to workaround patented domain control methods that 
involve a CA-generated secret.

> I notice that there are mentions of an API in that document.  If you
> have other API documentation you could share, that could be useful.  In

Here's the main page for our API documentation:
https://secure.comodo.com/api/

As PZB already noted, you can grab the latest versions of all of our API 
docs here:
https://secure.comodo.com/api/pdf/latest/

To see just the API docs that are relevant to SSL certs, look here:
https://secure.comodo.com/api/pdf/webhostreseller/sslcertificates/

BTW, I agree with PHB's summary at the top of this message...
http://www.ietf.org/mail-archive/web/acme/current/msg00096.html
...of how and why our APIs fall short of being ideal.

> --Richard
>
>
>
> On Mon, Dec 22, 2014 at 5:43 AM, Rob Stradling <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     https://secure.comodo.com/api/__pdf/latest/Domain%20Control%__20Validation.pdf
>     <https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf>
>
>         https://docs.google.com/a/ipv.__sx/document/d/1KVKIS6abA2KL-__yHvFsMql6U3qUjVhgO6p19Hzci0vQo__/edit?usp=sharing
>         <https://docs.google.com/a/ipv.sx/document/d/1KVKIS6abA2KL-yHvFsMql6U3qUjVhgO6p19Hzci0vQo/edit?usp=sharing>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Dec 2014 12:43:57 +0000

> https://secure.comodo.com/api/pdf/latest/AutoApplySSL.pdf is the primary

Yes, Robin sent me that link a while back but the conversation seemed to
have moved on to the signature discussion which seemed like better use of
time...

One of the things I want to do in the new year is to see whether I can
drive that API from a JSON frontend and what it looks like.

The only difference I can see is the introduction of an account concept..

---

From: Richard Barnes <[email-masked]>
Date: Tue, 23 Dec 2014 15:50:05 -0500

On Tue, Dec 23, 2014 at 7:29 AM, Rob Stradling <[email-masked]>
wrote:
> Hi Richard.  I don't recall any particularly good reason for why we chose
> to use CNAME instead of TXT.  I think it was just a case of sticking with
> what we knew would work and with what our customers were more likely to
> already be familiar with.
>
> register a CNAME record for <md5>.dreamhosters.com that points to <sha1>.
> comodoca.com.
> A colleague just said to me: "most shared hosts (like Dreamhost) designate
> that subdomain you request for webhosting and that it's incredibly unlikely
> (read: near-impossible) to get them to change their DNS for that to point
> anywhere other than their shared hosting servers."
>

I can confirm that this is the case with Dreamhost, having just tried the
experiment.  Nonetheless, this seems like kind of a fragile assumption,
given that there do exist some less-clueful hosting providers.

--Richard

> BTW, the reason I came up with the idea of using CSR hashes was because we
> were trying to workaround patented domain control methods that involve a
> CA-generated secret.
>
>>         https://docs.google.com/a/ipv.__sx/document/d/1KVKIS6abA2KL-__
>> yHvFsMql6U3qUjVhgO6p19Hzci0vQo__/edit?usp=sharing
>>         <https://docs.google.com/a/ipv.sx/document/d/1KVKIS6abA2KL-
>> yHvFsMql6U3qUjVhgO6p19Hzci0vQo/edit?usp=sharing>
>>
> this email may be monitored by COMODO for operational or business reasons.
> Whilst every endeavour is taken to ensure that e-mails are free from
> viruses, no liability can be accepted and the recipient is requested to use
> their own virus checking software.
>

---

From: Bernd Eckenfels <[email-masked]>
Date: Tue, 23 Dec 2014 22:00:18 +0100

Am Tue, 23 Dec 2014 15:50:05 -0500
schrieb Richard Barnes <[email-masked]>:

> > IIUC, you're suggesting that there's a risk that Dreamhost might
> > let you register a CNAME record for <md5>.dreamhosters.com that
> > points to <sha1>. comodoca.com.
> > incredibly unlikely (read: near-impossible) to get them to change
> > their DNS for that to point anywhere other than their shared
> > hosting servers."
> >
> 
> I can confirm that this is the case with Dreamhost, having just tried
> the experiment.  Nonetheless, this seems like kind of a fragile
> assumption, given that there do exist some less-clueful hosting
> providers.

Each dyndns provider does exactly that, allowing you to register a
record with an user chosen name pointing to any IP. This is at least
true for A records, but I could imagine similiar serives (host
forwarding servicde) for CNAME.

So TXT is better in that case (however none of them should be used
without a second factor like whois-mail or to not issue certificates
for the domain name without the host prefix (or even worse wildcards)).

Gruss
Bernd

---

From: Rob Stradling <[email-masked]>
Date: Mon, 29 Dec 2014 11:48:02 +0000

On 23/12/14 20:50, Richard Barnes wrote:
> On Tue, Dec 23, 2014 at 7:29 AM, Rob Stradling wrote:
>     sticking with what we knew would work and with what our customers
>     were more likely to already be familiar with.

Hi Richard.

Instead of using either CNAME or TXT for DNS-based domain validation in 
ACME, wouldn't it make more sense to use and extend CAA (RFC6844) ?

<snip>
>     IIUC, you're suggesting that there's a risk that Dreamhost might let
>     you register a CNAME record for <md5>.dreamhosters.com
>     <http://dreamhosters.com> that points to <sha1>.comodoca.com
>     <http://comodoca.com>.
>     their DNS for that to point anywhere other than their shared hosting
>     servers."
>
> assumption, given that there do exist some less-clueful hosting providers.
>
> --Richard

We're not aware of any less-clueful hosting providers who break our 
assumption, but I agree that the assumption is fragile given that there 
are such a huge number of webhosts across the world.

Let me just reiterate that this...

>     BTW, the reason I came up with the idea of using CSR hashes was
>     because we were trying to workaround patented domain control methods
>     that involve a CA-generated secret.

...was why we felt we had to make that fragile assumption.

If ACME can avoid making any fragile assumptions of this sort and can 
avoid infringing any patents, then I'll be happy.  :-)

<snip>