> 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? 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 v...@rhyolite.com _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs