On Fri, 07 Nov 2008 21:51:47 +0100, Dean Anderson <[EMAIL PROTECTED]> wrote:
On Thu, 6 Nov 2008, Yngve N. Pettersen (Developer Opera Software ASA)
This is better. But doesn't fix the underlying problem that breadth and
scope of administrative control can't be determined by opera, or by
anyone external to the administrative control. And
downloading/maintaining/controlling this file is another problem to
manage. Historically, this hasn't been found to be a very scalable
solution.
Please see sec. 2 and 2.1 (use of HTTPS for retrieval, and digital
signatures of content).
Also, trying to have opera determine and distribute this information
about what administrative domains there are on the internet is another
serious problem. Not least of which, downloading the results of opera
project's scanning is also a security concern.
Please see Appendix A (possible methods for collecting the information)
If you mean to have a file determined by the admin domain itself, client
and server need to authenticate and verify that file---with what
certificate? Who knows if the certificate offered is the __right__
Again, see sec 2 and appendix A. Actual information collection is outside
the scope of the current version of this draft, because there are multiple
methods; a separate specification will be needed for that part.
certificate? Only the user can figure that out. So you haven't made
things any easier for the user; they STILL need to verify certificates.
Opera is already downloading root certificates from a digitally signed
online repository using a secure connection, and the download is done in a
fashion that the user will NOT be asked about certificates concerning that
download. A dynamic download of the TLD structure information would be
done in a similar manner, without user interaction.
Well, as I've mentioned earlier, cookies is the area that have spurred
my development of this specification. It is not the only area asking
for such information, as I've also mentioned earlier, for example URL
display in FF3 and IE8, and if I am not mistaken, Google Chrome. And
there are likely more.
I'm not familiar with these proposed uses. But it would seem on the
surface that they are solved by the same http/cookie change as I
suggested.
I doubt that, they are needed in areas that are not using cookies, such as
presentation of URL strings.
In any case: Google, Microsoft and Mozilla are ALL, right now, deploying
browsers using Mozilla's PublicSuffix database, and two of them have been
doing so for more than 6 months.
One area where developers want to use such information is to help
users understand where they actually are on the Internet, for example
when being directed somehow to
"www.my-trusted-bank.com.foo.bar.and.something.else.malicious.example.net",
by highlighting "malicious.example.net", and making the rest almost
invisible.
That is a very subjective distinction. Who knows whether
malicious.example.net is actually malicious? 'Malice' is a property
that can't be determined by finite automata. It cannot be done
automatically. However, the security and trust aspect is easily handled
by using SSL and teaching USERS how to properly verify the certificates.
There is no way around that requirement; There are only two cases: If
the users don't verify trust properly, they can't ever be sure of the
trusted authenticity of the server. If the users do verify properly,
there is no way to fool them.
I suspect you misunderstand what the example is really about.
It is about a widely used spoofing attack against users.
An ordinary user would look at the beginning of the above hostname,
"www.my-trusted-bank.com", and *ignore* the remainder of the name because
they have been trained to look for that particular name, often missing the
crucial part of a "/" being needed immediately afterwards. That is also
what made http://[EMAIL PROTECTED]/ such a nice tool for
spoof stories until browsers made it much harder to use that method.
The result is that the user will believe they are on the trusted site, and
may provide the site with important credentials.
The method used by Microsoft in IE8 Beta 1 (relased in March) is to
highlight the real domain of the site, making it possible for an observant
user to detect the discrepancy between what they expected their online
location to be, and the reality.
It is not a complete solution, but it is part of what a browser can do to
better inform the user, also on non-secure sites.
without the interaction of the user. You are merely trying to grapple
the impossible, without realizing it is impossible.
Even if something is, strictly speaking, "impossible" (like calulating the
exact numerical value of Pi), a good approximation (3.14159) will most
often be sufficiently accurate for ordinary use, nor does it mean that we
should not try to discover and use sufficiently good approximations.
(Another example is IDNAbis)
Opera is currently using one approximation for cookie domain validation,
using DNS, described in the "DNSCOOKIE" draft; Mozilla and PublicSuffix
are probably using a much better approximation, information that can be
used in the subTLD structure protocol.
IMO, an even better approximation to what our applications need for
various automatic security features, would be a list of registry-like
domains provided by the TLD regisitries.
If there are better approximations the DNSOp WG and other interested
parties are encouraged to come forward with them.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: [EMAIL PROTECTED]
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
