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