On 10/21/2013 08:54 AM, Keith Mitchell wrote:
Applying the same 5-years' now-outside hindsight to this, the benefits
of all that port randomization work seem murky at best - does anyone
have data on many real Kaminsky cache-poisoning attacks took place in
that time ?
The Kaminsky vulnerability
Colm MacCárthaigh c...@stdlib.net wrote:
This thread concerns the vulnerabilities uncovered in the fragment
attacks. One of those vulnerabilities is that domains can be rendered
unresolvable; even when DNSSEC is enabled. That seems like something
to take seriously.
I am incresingly doubtful
Vernon Schryver v...@rhyolite.com wrote:
Have you turned on DNSSEC where you can? If not, why not?
Can we have less of the ad hominem please.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough,
On Oct 21, 2013, at 14:32, someone wrote:
But who cares who got there first? Every request
I see for credit is recorded in my private accounting as a debit against
the credibility of the person demanding credit, because credit demands
suggest interests which suggest biases and so
Which brings me to the topic of resolver-behind-upstream attacks which were
not commented upon.
As you know, one of the recommendations of experts and Internet operators,
following Kaminsky attack, was `either deploy patches or configure your
resolver to use a secure upstream forwarder`,
On Tue, Oct 22, 2013 at 6:20 PM, Rubens Kuhl rube...@nic.br wrote:
Which brings me to the topic of resolver-behind-upstream attacks which
were not commented upon.
As you know, one of the recommendations of experts and Internet operators,
following Kaminsky attack, was `either deploy patches
On 10/22/2013 10:52 AM, Haya Shulman wrote:
Disclosing such potential vulnerabilities remains valuable work,
but I think careful consideration needs to be applied to the
engineering economics of the best operational-world mitigation
approaches.
@/Keith Mitchell/
(My head is *really*
On Tuesday, October 22, 2013 18:57:41 Haya Shulman wrote:
On Tue, Oct 22, 2013 at 6:20 PM, Rubens Kuhl rube...@nic.br wrote:
Would DNSCrypt, supported by OpenDNS, be a possible mitigation to this
issue?
...
Would IPSEC between resolver and upstream forward be a possible
mitigation to
I am not sure what you mean by `official OARC channels`, I forwarded my
communication on this issue, with porttest operators, to you a month or so
ago. Maybe these were not official channels, but I have not contacted OARC
otherwise, via a different channel.
Can you please advise how to contact
From: Haya Shulman haya.shul...@gmail.com
Please read my first post in this thread, you should find all information
there.
I see I'm stupid for not seeing that in the first message. I did search
for 'http' but somehow didn't see the URL. But why not simply repeat
the URL for people like me?
On 10/22/2013 02:41 PM, Haya Shulman wrote:
Yes, but as I explained privately previously, there is no record
of this correspondence through official OARC channels - I did
request you re-send, but I don't have a copy of it.
I am not sure what you mean by `official OARC channels`, I forwarded
On Oct 22, 2013, at 7:42 AM, Daniel Kalchev dan...@digsys.bg wrote:
I for one, do not believe DNSSEC is any difficult. I have turned DNSSEC
wherever I can. It has become easier and easier in the past few years to the
point I would call deploying DNSSEC today trivial. I have therefore
On 22 Oct 2013, at 20:28, Jared Mauch ja...@puck.nether.net
wrote:
It's difficult because there is not universal support amongst registrars.
Once again the wheel gets stuck when the technical side meets the business
side.
It's not entirely business that causes the issues ..
Haya Shulman wrote:
so if i add first weaponized by Haya Shulman this would
settle the
matter?
Thank you, can you please use Amir Herzberg and Haya Shulman (I
collaborated on this attack together with my phd advisor Amir
Herzberg).
it shall be
Jared Mauch wrote:
...
Edit a zone file vs edit, run a script, upload some keys, roll some keys, do
some other magic is harder than edit a zone file.
BIND9 V9.9 may surprise you. it has inline signing and automatic key
management. the code name for this feature set was DNSSEC For Humans
and
Em 22/10/2013, às 18:06:000, Michele Neylon - Blacknight escreveu:
On 22 Oct 2013, at 20:28, Jared Mauch ja...@puck.nether.net
wrote:
It's difficult because there is not universal support amongst registrars.
Once again the wheel gets stuck when the technical side meets the business
On 22 Oct 2013, at 22:53, Rubens Kuhl rube...@nic.br wrote:
.nl and .cz got massive registrar adoption to DNSSEC offering business
incentives, so it seems business side accounts for most of it.
So where are the incentives for resolver operators? If they switch on DNSSEC
validation and get
I'm puzzled by the explanation of Socket Overloading in
https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf
I understand it to say that Linux on a 3 GHz CPU receiving 25,000
packets/second (500 bytes @ 100 Mbit/sec) spends so much time in
interrupt code that low level packet
I am not at liberty to disclose location or vendor, but I'm aware of linux
boxes handling 20k PPS mixed UDP/TCP at an average 2% CPU. They aren't even
modern boxes although a bit newer than the dual core that Vernon mentions
below. In short, I agree completely with everything Vernon said here.
Em 22/10/2013, às 20:40, Jim Reid escreveu:
On 22 Oct 2013, at 22:53, Rubens Kuhl rube...@nic.br wrote:
.nl and .cz got massive registrar adoption to DNSSEC offering business
incentives, so it seems business side accounts for most of it.
So where are the incentives for resolver
Vernon Schryver wrote:
I'm puzzled by the explanation of Socket Overloading in
https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf
I understand it to say that Linux on a 3 GHz CPU receiving 25,000
packets/second (500 bytes @ 100 Mbit/sec) spends so much time in
interrupt
21 matches
Mail list logo
