On Jan 9, 2017, at 10:14 AM, Paul Wouters <p...@nohats.ca> wrote: > Apple is getting ready to drop port 80 support. unsigned/unencrypted > transports are dying. I hope we are moving to a word where DNS without > DNSSEC will also be seen as bad. So yes, I am assuming in the future, > attackers will have to sign DNS and that domains without DNSSEC are seen > as "rogue domains that don't have clear audit trails".
It remains the case that most service providers at present appear to believe that PKI is enough, and they don't think DNSSEC is worth the trouble. Like you, I look forward to the day when this is no longer true, although I don't look forward to the attack that changes peoples' minds about this. >> I think this is actually not true: why is a DS record any more of an audit >> train than an NS record? > > Because it proves ownership of the domain. My nohats.ca DS record cannot > be modified by the UK ISPs forced to filter my domain. But they can > spoof NS records. See the recent discovery that Heathrow Airport runs a > MITM TLS server on torproject.org. Do we want them to run RPZ where they > can disappear torproject.org alltogether? No. Do we want them to run RPZ > to prevent travelers from getting malware installed? Yes. We are talking at cross purposes. We agree that the DS record proves ownership of the zone. But it doesn't provide any more of an audit trail in terms of zone setup than does an NS record. In terms of accurately identifying who set up the zone, it is completely useless. >> Your point here, that in order for RPZ to function in the presence of >> widespread DNSSEC signing, there has to be some mechanism for authenticating >> RPZ answers _as_ RPZ answers, doesn't seem clearly true. It >> may be perfectly functional for RPZ answers to look like an attack. But >> it's certainly worth considering, and has been talked about earlier in this >> thread. The question is, does it make sense to add code >> to the validating resolver to detect and validate an RPZ block, so the user >> can be informed that a block occurred, and who did it? Would people >> actually code this up? Would it be better or worse? > > To me that is quite obvious "yes". If we allow the DNS protocol to > randomly rewrite DNS, then why _do_ we have DNSSEC? Again, not the point I was making. Of course we want the resolver to do validation. The question is, do we want the resolver to have code in it to validate who did the RPZ block. I think this would be a really bad idea, and would be seriously damaging to human rights. > Excellent! It means if the RPZ/DNS provider screws up, they are > accountable. And they will properly maintain such systems that > are golden opportunity for hackers to compromise. Also, the > danger you are describing "I can make an attack look like protection to > the end user" is exactly what the current RPZ spec already allows! > I guess you really meant to say "a compromised RPZ system can unblock > a malicious and previously blocked side". Well yes. You are describing > a weakness, not a strength, of the RPZ solution. You are thinking like a IETF geek. The average end user will know nothing of this. To them, it will simply be the case that their computer says "this is a malware site." They will not see the audit trail. It doesn't matter if the ACLU can detect the attack: they could have detected the attack without the signature, and most likely had a clear idea of who did it. What matters is that we have no provided a way for malicious site operators to lie to end users, who will not be able to detect the lie. To be clear, the lie is "I am authorized to block zones on your behalf." > Just blocking the domain is "too much". And in my view that _is_ the > human rights issue. We disagree here. I have seen way too many people screwed over by malware to think that preserving a perfect uncensored view of the DNS is more important than blocking malware. As long as we can tell that we have been given a filtered response, I think we have the best possible compromise, and if sites are not willing to put in the effort to sign their zones, that is their problem. > If we change this discussion and replace DNS and DNSSEC with BGP and > RPKI, would you still think it is fine to allow random parties to > change BGP announcements in a world of secure BGP so that users can > be prevented to go to certain IP ranges? If that IP range is being operated by a malware site or for example is going to redirect all of my traffic through a country that is sniffing my packets for intelligence purposes, then yes, it should be possible for the infrastructure to prevent the broken route from being installed, regardless of whether or not it has been signed. This is the distinction between authentication and authorization that we all know so well: just because something is _authentic_ does not mean that it is authorized. Taking that very clear distinction and turning it political is not helping anyone. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
