I believe this draft is insufficient:
4.1: Frankly speaking, with all the mechanisms out there, you must
assume that an attacker can force queries of the attacker's choosing
at times of the attacker's choosing, within a fraction of a second in
almost all cases. This is not by directly gen
On Oct 9, 2008, at 9:52 AM, Ólafur Guðmundsson /DNSEXT chair wrote:
At 19:17 02/10/2008, Nicholas Weaver wrote:
I believe this draft is insufficient:
4.1: Frankly speaking, with all the mechanisms out there, you must
assume that an attacker can force queries of the attacker's choosi
On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote:
FYI, there's at least one more proposal in this space: the Ono stuff
from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html
). There was a paper at SIGCOMM this year, and their system has the
interesting feature that it s
Hey, stupid thought...
Could you do proximity based on "who's your DNS resolver"? Do a few
name lookups: one to register YOU as using YOUR DNS resolver to the
remote coordinator, and one to get "who are other peers using the same
resolver"?
An ugly, UGLY hack, but it might be interesting
On Nov 18, 2008, at 10:53 AM, Scott Brim wrote:
Excerpts from Randy Bush on Tue, Nov 18, 2008 10:39:57AM -0600:
[EMAIL PROTECTED] wrote:
I believe our US government would like to grant visas to as many
people as they can. However, if anyone wants to attend a meeting in
the US is granted a vis
On Nov 18, 2008, at 3:56 PM, Livingood, Jason wrote:
I recall stats from IETF 71 (which may be out of date). I believe at
that time, 48% of attendees were from the U.S. Next was Japan with
9%,
then China with 5.7%. If I recall correctly, this was a good number
of
attendees from China, bu
I've added the ALTO mailing list to this discussion:
What it comes down to is you want "localization", not RFC 3484.
On Mar 4, 2009, at 8:05 AM, Ondřej Surý wrote:
On Wed, Mar 4, 2009 at 4:17 PM, Paul Vixie wrote:
dns-based load balancing is an unfortunate overloading and
should never be d
addition will include the ability to add a NONCE to guarantee
cache-busting, too).
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.ics
es are generated on the fly, are
almost certainly going to be developed to utilize this infrastructure.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .sig
p on the
TLS PKI for their own use in Chrome: they hardcode the Google sub-CA.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi
nly a single CA, you end up having to trust the entire universe of
certificate authorities.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
P
11 matches
Mail list logo
