[cabfpub] Domain validation

[Ryan Sleevi]

On Thu, May 7, 2015 at 1:09 PM, Tim Hollebeek <THollebeek at trustwave.com> wrote:
> In the #10 use case Gerv was discussing, the certificates are self-signed,
> so the TLS-ness doesn’t provide much value, so it doesn’t matter where the
> TLS terminates.  If we’re going to allow that, I think we should make it
> explicit what we’re allowing (self-signed or untrusted certificates), and
> also enforce the .well_known requirement for the same reasons why we did it
> for #6.

Hi Tim,

I think you're still confused here. The certificates being self-signed
or not don't matter for the attack scenario.

That is, in an Appspot/Azure case, the user has the ability to
manipulate the filesystem, but not open/listen on sockets. That's a
necessary condition to meet the criteria for #10, but not for #6,
which is why they're not equal.

It's similar to the discussions about DNS modifications. The ability
to place a file on a server doesn't mean you can modify a DNS record.
That's why #10 is different than the DNS-based system.

My point is that #10 requires control of sockets, the email solutions
require control of the MX record & email server, the DNS based
solutions require control of DNS records (which may have been
delegated resolvers or be the registered domain). Compare all of this
to #6, which just requires control of a file path - which is a
significantly different security model from the rest.