On 2/11/11 5:57 AM, Eddy Nigg wrote:
On 02/11/2011 07:08 AM, From Steve Schultze:
Can you give an example?
Who the subscriber is (not higher level validation, sanity check)
I still can't decipher this.
what the requested host name is
There is no ambiguity in DANE.
what's the purpose of a certificate
There is no ambiguity in DANE
cryptographic weaknesses
Better done in the client.
Would these checks be necessary under DANE or are they specific to the
CA third-party-domain-validator model?
I believe that they are necessary and requires involvement of a third
party (if you want, you can call it something else than CA ;-) )
With DANE, such checks are part of the spec and the client
implementation. As we have seen repeatedly on m.d.s.p., relying on CAs
to enforce checks consistently is far less effective than implementing
hard client checks.
Well, as a matter of fact, the specs exists today for CAs too and are
not enforced on the client side. What makes you believe that anything
will change in this respect? By all means, how should individual users
be more compliant to specs than CAs?
Right, the spec exists today for CAs and we continue to see problems
with enforcement.
Individual users do not need to implement the checks, the client
validating resolvers do. This is a far smaller surface area than the
thousands of entities issuing DV CA certs.
Unnecessary with DANE.
A review of the requested properties in a certificate are an obvious
benefit, it's not unnecessary with keys-in DNS, it's not possible.
The only relevant properties are domain and key. The domain is implicit
and the key needs no review other than basic sanity checks done in the
client.
I've made clear that I'm not a fan of such nannyism.
So? Maybe you are not (that's your own problem which is not shared by
the software vendors amongst other things), but it's a one of the tools
CAs have and use when necessary.
My policy position, shared by many, is that giving arbitrary
intermediaries control of internet communications is not a good idea.
Mozilla's approach to anti-phishing and malware protection supports this
approach by giving clients tools to make their own decisions.
To the extent that it has to be done, the registries/registrars are
simply a more direct path.
You make me laugh
<snip>
I readily concede that some CAs have revoked DV certs for sites that
were doing things that most people would consider "bad", and perhaps
that revocation actually prevented them from doing more "bad" things
(although I suspect that the vast majority of phishing/malware/etc
doesn't rely on HTTPS whatsoever). I do know that millions of domains
accused of such behavior have been removed by just one NIC. Which is
more "effective"? It's not clear.
In any case, the policy question of whether policing by intermediaries
is a good thing makes it complicated to say whether or not we should
value more "effective" policing in the first place.
Mozilla does not consider CA revocation for "bad behavior" as a factor
in accepting DV root certs (nor do I imagine that they want to be in
that business).
But all of the above has to do with your claims about what disadvantages
DANE has relative to CA DV. You persistently ignore the clear
disadvantages of CA DV relative to DANE, such as exclusivity,
delegation, smaller surface area of vulnerabilities, etc.
CAs stand to benefit greatly by leveraging DANE to add these
characteristics to their more highly validated certs. They should be
cheerleading such efforts (and several are).
Your pattern of reasoning, on the other hand, is to assert that DV CAs
simply "know best" -- therefore we should continue to let them insert
themselves into a process that could be run far more securely and
efficiently without a third party. I don't buy it.
Steve
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
