Re: [Acme] Threat model for claiming domains

[Rob Stradling <[e-mail]>]

On 22/12/14 14:29, Richard Barnes wrote:
> 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?

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
> particular, it would make it easier to make ACME something that you guys
> could transition to :)

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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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
>     <https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf>
>
>     On 20/12/14 00:25, Richard Barnes wrote:
>
>         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
>         <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 <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> 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
>
>
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
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.