On Tue, Dec 23, 2014 at 7:29 AM, Rob Stradling <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >> > -- > 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. >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
