At 12:49 PM +0100 2/26/09, Jean-Marc Desperrier wrote: >Just one thing : The use of a wildcard certificate was a misleading red >herring in the implementation of the attack. > >What's truly broken is that the current i18n attack protection relies on the >checking done by the registrar/IDN, and that the registrar/IDN can only check >the second-level domain name component. > >Once they have obtained their domain name, attacker can freely use the >third-level domain name component to implement any i18n attack they want even >if no wildcard certificate is authorized.
The author was showing that even looking at the lock doesn't help in a spoofing attack if the attacker has a wildcard certificate. In this way, it is an attack improvement. >This is not to say that wildcard certificates are not bad, evil, anything, but >that nothing new has been truly brought about that by this attack. > >So talk about wildcard certificate all you want, but this is a separate >discussion from the discussion about the solution for this new i18n attack. >And the solution for it will not be wildcard certificate related, will not be >easy or obvious, and so needs to be discussed as widely as possible. >Also there will be no crypto involved in the solution, as it's not acceptable >to choose to just leave ordinary DNS user out in the cold with regard to the >attack. So it needs to be discussed on the security group, not crypto. We disagree here: it should be discussed in both places. In "security", it is what should the browser do about spoofing. In crypto-policy (or whatever that list will be called when it is turned on), it should be how wildcards assist in the attack if a user is looking at the lock. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
