[dns-operations] summary of recent vulnerabilities in DNS security.
vjs at rhyolite.com
Tue Oct 22 18:51:50 UTC 2013
> From: Haya Shulman <haya.shulman at gmail.com>
> Please read my first post in this thread, you should find all information
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? Why not the URL of the paper at the
beginning instead of a list of papers?
By searching for "DNSSEC" with my PDF viewer, I found what I consider
too few references to the effectiveness of DNSSEC against the attacks.
There is nothing about DNSSEC in the abstract, a list of DNSSEC problems
early, and a DNSSEC recommendation in the conclusion that reads to me
like a concession to a referee. Others will disagree.
After skimming the papers at
since at first I was not sure which one (my fault), I've the
impression that Haya Shulman doesn't like:
- forwarding to third party resolvers.
I agree so strongly that feels like a straw man. I think
forwarding to third pary resolvers is an intolerable and
unnecessary privacy and security hole. Others disagree.
- other mistakes
that I think are even worse than forwarders.
Perhaps that will be denied, but I challenge others to read those
papers with their litanies of DNSSEC issues and get an impression
of DNSSEC other than "sow's ear sold as silk." That was right
for DNSSEC in the past. Maybe it will be right forever. I hope
not, but only years will tell. As far as I can tell from a quick
reading, the DNSSEC issues are valid, but are sometimes backward
looking, perhaps due to publication delays. For example, default
verifying now in server software and verifying by resolvers such
as 22.214.171.124 should help the verifying situation.
> > work on DNSSEC improvements and bug fixes before or after your
> > issues?
> Requiring such answers from me is absolutely out of place, I am
> probably not aware of the constraints that organisations face in their
> every day operation of the Internet, and so I never argued which
> coutermeasures must be deployed and by whom. My goal is to identify
> vulnerabilities and investigate and recommend countermeasures that can
> prevent them. Each organisation should decide what solution suites its
> needs best, based on this and other information that is available to
That non-answer "is absolutely out of place" given Haya Shulman's
"recommendations." It is unacceptable to preassume enough "awareness
of constraints" etc. to tell people 'Do this, that, and the other' but
be unwilling to say whether those actions should be done before or
after closely related work. This is especially true in this mailing
list, because for operators the recommendations are functionally
equivalent to "do nothing but wait for new DNS software."
> Port randomization is an extremely thin reed for security, because
> > there are so few port number bits.
> There are techniques to artificially inflate ports' distribution, and we
> already described one technique in ESORICS'12 paper.
Would that paper be
linked from https://sites.google.com/site/hayashulman/pub ?
If so, where or how can I find a free version or a summary of the
notion? Getting more than 16 bits of entropy from a 16 bit value
sounds interesting. (I trust it's not that literal impossibility.)
I've heard of
- jumbling domain case,
but that suffers from limitations in resolver cache code
and it's not part of the UDP port number,
- other fiddling with the payload, but they're not the port number,
- the ID, but that's not the UDP port number,
Vernon Schryver vjs at rhyolite.com
More information about the dns-operations