Re: [Acme] Threat model for claiming domains

[Richard Barnes <[e-mail]>]

On Tue, Dec 23, 2014 at 7:29 AM, Rob Stradling <[e-mail]>
wrote:
>
> 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."
>

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