[cabfpub] Domain validation
sleevi at google.com
Thu May 7 13:48:22 MST 2015
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.
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.
More information about the Public