[dns-operations] summary of recent vulnerabilities in DNS security.

[Vernon Schryver]

> From: Haya Shulman <haya.shulman at 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?  Why not the URL of the paper at the
beginning instead of a list of papers?
https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf

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 
https://sites.google.com/site/hayashulman/publications
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.

 - DNSSEC
    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 8.8.8.8 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
> it.

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 
http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16
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