[messaging] What counts as proof of ownership?

[Tao Effect]

Hi Daniel,

The more things about a domain you can change, the greater proof it is that you can control over it.

The fewer requirements there are, the easier it is to attack.

The more requirements you add, the more you shrink the set of potential malicious actors who can forge ownership.

Cheers,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Jan 19, 2015, at 3:26 PM, Daniel Roesler <diafygi at gmail.com> wrote:

> Howdy all,
> 
> Over the weekend, I made a script that gets certificate signing
> requests signed by the Let's Encrypt Demo CA[1]. You have to prove to
> the CA that you own the domain you're requesting a signature for, so I
> spent quite a bit of time digging into the ACME spec for automatically
> determining ownership of a domain[2].
> 
> So it got me wondering what is considered best practice or ideal for
> proving your ownership of a resource? What will create the widest
> adoption? What will people trust?
> 
> For ACME, there are several challenges that can prove you have control
> over the domain:
> 
> 1. Simple HTTPS - Serve a specific file at a specific domain on port 443
> 2. DVSNI - Serve a TLS cert with a specific subjectAltName on port 443
> 3. DNS - Add a specific TXT record to your DNS
> 4. Email (undocumented, possibly in the future)
> 5. DNSSEC (undocumented, possibly in the future)
> 6. WHOIS (undocumented, possibly in the future)
> 
> For KeyBase, #1 or #3 is used[3]. For StartSSL, Comodo, and other SSL
> cert retailers, #4 and #6 are used[4]. App.net and Google use html
> tags to verify ownership (which is not on the ACME list)[5][6]. EV
> certificates require a legal entity to be verified[7].
> 
> What about other resources? Package managers use PGP keys to sign
> packages (yet another method). As far as I know there's not a similar
> way to sign javascript libraries that you might serve from a CDN, but
> clients could use Subresource Integrity[8] to manually restrict file
> hashes. another great use for signed code instead of TLS would be for
> keyserver pools like SKS[9].
> 
> So what's best? We have a ton of methods for proving ownership of
> domains and web content, which makes things very confusing.
> 
> -Daniel
> 
> [1]: https://github.com/diafygi/letsencrypt-nosudo
> [2]: https://letsencrypt.github.io/acme-spec/#rfc.section.6
> [3]: https://github.com/keybase/keybase-issues/issues/261
> [4]: https://konklone.com/post/switch-to-https-now-for-free
> [5]: http://blog.app.net/2013/04/29/announcing-domain-verification/
> [6]: https://support.google.com/webmasters/answer/35179?hl=en
> [7]: https://cabforum.org/overview-of-the-extended-validation-ssl-vetting-process/
> [8]: http://www.w3.org/TR/SRI/
> [9]: https://sks-keyservers.net/overview-of-pools.php
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150119/b9f749cb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150119/b9f749cb/attachment.sig>