Eddy Nigg wrote:
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
[...]
Only CAs are relevant if at all. You don't expect that 200 domain names
were registered by going through anti-spoofing checking and measures, do
you?!
[...]
Outsh, sorry! That should have
Paul Hoffman wrote:
At 7:09 AM +0100 2/24/09, Kaspar Brand wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard
On 26/02/09 11:05, Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
[...]
Only CAs are relevant if at all. You don't expect that 200 domain names
were registered by going through anti-spoofing checking and
measures, do
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
On 23/02/09 23:54, Eddy Nigg wrote:
How to prove? Does Mozilla buy domain names (or purchase certificates)
from time to time in order to govern its policies?
We rely on good citizens like you to let us know when there's a problem
:-) We don't regularly attempt to break the security of CA cert
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
How to prove? Does Mozilla buy domain names (or purchase certificates)
from time to time in order to govern its policies?
We rely on good citizens like you to let us know when there's a problem
:-) We don't regularly
On 24/2/09 02:11, Eddy Nigg wrote:
On 02/24/2009 02:35 AM, Ian G:
The point that is made is that the positive response is so weak that
it doesn't support the overall effect; the attacker just prefers to
trick the user using HTTP and some favicons or other simple symbols. And
(so the author
On 02/24/2009 01:47 PM, Ian G:
Right. This can also be seen as evidence that secure browsing has not
protected the users, because it was so easily bypassed.
Orthe price to stage an attack using SSL is still considered too
high. It's rather a point for SSL than against IMO.
If the
At 7:09 AM +0100 2/24/09, Kaspar Brand wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard certificates - just read the
Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-20 10:28:
[...] CA guidelines
Which (whose) guidelines? Are you referring to RFC 5280 section 7, or
to some other guidelines?
Mozilla's CA cert policy doesn't even mention this subject.
say that certificates should not be issued
Paul Hoffman wrote:
TLD registries ask which language a name is in; some then do some
filtering based on what characters they think are used by particular
languages. This is far from a science and fails miserably for most
European languages.
If it fails, then report it to secur...@mozilla.org
On 02/23/2009 02:01 PM, Jean-Marc Desperrier:
When issuing a SSL server cert there is no need for a special checking
at the CA level, because nobody will first be able to obtain a dangerous
domain name within that TLD.
Like the IANA requirement to state correct information in the WHOIS
On 23/2/09 13:41, Eddy Nigg wrote:
On 02/23/2009 02:01 PM, Jean-Marc Desperrier:
When issuing a SSL server cert there is no need for a special checking
at the CA level, because nobody will first be able to obtain a dangerous
domain name within that TLD.
Like the IANA requirement to state
At 1:14 PM +0100 2/23/09, Jean-Marc Desperrier wrote:
Paul Hoffman wrote:
TLD registries ask which language a name is in; some then do some
filtering based on what characters they think are used by particular
languages. This is far from a science and fails miserably for most
European languages.
At 2:19 AM +0200 2/23/09, Eddy Nigg wrote:
You don't like that I mention particular CAs, but the one I'm affiliated with
does to some extend. ;-)
I do not like you mentioning particular CAs to advertise (yourself) or attack
(your competitor); asking for a list of CAs that implement policies
Jean-Marc Desperrier wrote, On 2009-02-23 04:01:
Nelson and everyone else not knowing the details of this :
The problem is solved not at the CA level, but at the registry/TLD level.
I think you mean that IF it were solved, the solution would be at ...
But I think it is evident that it is NOT
On 02/23/2009 04:57 PM, Ian G:
* IDNs present more danger than wildcards,
* wildcards present more danger than IDNs,
* they are approximately the same level of danger,
and trying to separate them out is not efficacious
at this level of discussion?
Anything which can be misused in such a way
On 23/02/09 17:58, Paul Hoffman wrote:
Jean-Marc, you have fallen for Gerv's wishful thinking and security
theater. There are multiple TLDs on that list that have policies that
say *nothing* about preventing homograph spoofing.
Every TLD on that list should have a published set of characters
On 19/02/09 17:36, Ian G wrote:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
You'll need to elaborate on what you are saying here, because the way I
read it, he _hates_ the new FF3
On 02/24/2009 01:18 AM, Gervase Markham:
The rationale section of this document explains very well why our
policy and technical implementation is as it is:
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
OK, reading the IDN policy I understand that registrars uses human,
On 02/24/2009 01:23 AM, Gervase Markham:
All the registries added to the list had this when they were added. As I
said in my previous message, if you know of a registry which no longer
meets these criteria, please let me know.
How to prove? Does Mozilla buy domain names (or purchase
Eddy:
It's important to realize something rather important... security must
be designed into the system from the ground up, and all pieces of a
secure system must operate together properly. It's not *just* the CA,
it's everything.
Since we don't have a secure system, we need to find a way to
On 02/24/2009 02:01 AM, Kyle Hamilton:
It's important to realize something rather important... security must
be designed into the system from the ground up, and all pieces of a
secure system must operate together properly. It's not *just* the CA,
it's everything.
Ideally yes, your are
On Mon, Feb 23, 2009 at 4:10 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 02/24/2009 02:01 AM, Kyle Hamilton:
It's important to realize something rather important... security must
be designed into the system from the ground up, and all pieces of a
secure system must operate together
On 24/2/09 00:20, Gervase Markham wrote:
On 19/02/09 17:36, Ian G wrote:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
You'll need to elaborate on what you are saying here, because the way
To amplify the response to Gerv's question on positive / negative
imbalance in responses in FF3, here's a forward from another list.
On 21/2/09 15:34, Peter Gutmann wrote:
Steven M. Bellovins...@cs.columbia.edu writes:
http://www.theregister.co.uk/2009/02/19/ssl_busting_demo/ -- we've
On 02/24/2009 02:35 AM, Ian G:
The point that is made is that the positive response is so weak that
it doesn't support the overall effect; the attacker just prefers to
trick the user using HTTP and some favicons or other simple symbols. And
(so the author claims) gets away with it easily enough,
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard certificates - just read the last paragraph of section
4.2.1.7/4.2.1.6. PKIX
RFC 2818 (HTTP Over TLS), section 3.1.
-Kyle H
On Mon, Feb 23, 2009 at 10:09 PM, Kaspar Brand m...@velox.ch wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely
Kyle Hamilton wrote:
RFC 2818 (HTTP Over TLS), section 3.1.
Definitely not a PKIX RFC. Removal of support for wildcards doesn't
need any PKIX action.
Kaspar
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On Sat, Feb 21, 2009 at 1:19 PM, Paul Hoffman phoff...@proper.com wrote:
I don't see how the attack could have been done without wildcards. CA
guidelines say that certificates should not be issued with homographic
characters that might cause confusion
They do? Where?
I believe that Unicode
Paul Hoffman wrote:
UTR #36 is not a CA guideline, it is a guideline that some CAs might
read and implement. I know of none that have.
I think part of what's going on here is a confusion between CAs and
domain name registrars. IIRC there was indeed some sort of agreement
among domain name
On 02/21/2009 11:19 PM, Paul Hoffman:
I don't see how the attack could have been done without wildcards. CA
guidelines say that certificates should not be issued with homographic
characters that might cause confusion
They do? Where?
Some CA policies do. I can't recall right now, but EV might
On 20/2/09 20:07, Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-20 10:28:
Homomorphic characters aren't a problem for wildcard matching. They're a
problem for users' eyeballs. The attack that was demonstrated could have
been done without wildcards. Changing the wildcard
At 1:28 PM -0500 2/20/09, Benjamin Smedberg wrote:
On 2/20/09 12:11 PM, Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-19 07:39:
It sounds to me that we could and should fix this bug simply by disabling
punycode for the wildcard portion.
I'm not sure what you're proposing here,
On Sat, Feb 21, 2009 at 1:19 PM, Paul Hoffman phoff...@proper.com wrote:
I don't see how the attack could have been done without wildcards. CA
guidelines say that certificates should not be issued with homographic
characters that might cause confusion
They do? Where?
I believe that Unicode
Eddy Nigg wrote:
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
.cn is
Benjamin Smedberg wrote, On 2009-02-19 07:39:
It sounds to me that we could and should fix this bug simply by disabling
punycode for the wildcard portion.
I'm not sure what you're proposing here, Ben, or what effect you think
it would have.
Homomorphic characters aren't a problem for wildcard
On 02/20/2009 08:28 PM, Benjamin Smedberg:
I don't see how the attack could have been done without wildcards. CA
guidelines say that certificates should not be issued with homographic
characters that might cause confusion, and as far as we know these
guidelines are being followed. The attack
Benjamin Smedberg wrote, On 2009-02-20 10:28:
On 2/20/09 12:11 PM, Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-19 07:39:
It sounds to me that we could and should fix this bug simply by disabling
punycode for the wildcard portion.
I'm not sure what you're proposing here, Ben,
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
.cn is authorized for i18n, and
On 2/19/09 9:37 AM, Eddy Nigg wrote:
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
On 19/2/09 14:30, Jean-Marc Desperrier wrote:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
PS : Some of his other remarks
On 19/2/09 16:39, Benjamin Smedberg wrote:
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
Other than this specific attack, what are the concerns about wildcards that
would make us take such a drastic action?
It sounds to me that we
On 02/19/2009 05:39 PM, Benjamin Smedberg:
Other than this specific attack, what are the concerns about wildcards that
would make us take such a drastic action?
It sounds to me that we could and should fix this bug simply by disabling
punycode for the wildcard portion.
Because punycode isn't
On 02/19/2009 07:36 PM, Ian G:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
I don't think this is what he is saying exactly, but rather that for
HTTP the world looks always fine...
46 matches
Mail list logo
