On 8/20/14, Hosnieh Rafiee <[email protected]> wrote: >> >> > I provided several reason that the observer doesn't exist. >> >> No, you provided several reasons why you think this decision is an >> unreasonable one. Prior to the evidence from a couple years ago that >> national governments were doing wide-spread vacuuming up of everything >> they could by perfoming passive attack through the means of tapping >> lines and so on, the position you are taking was entirely reasonable. >> But in the face of that evidence, some people have decided that, even >> if they can't protect themselves reliably all the time, they get enough >> marginal benefit from privacy to do it whenever they can, even if it's >> not perfect and not terribly hard to subvert. >> >> In other words, you are basically arguing that the benefit that will >> accrue from this technique is not enough given the costs. Others >> disagree with you. Your argument only works if we accept your premise >> that the benefit is not worth the cost; if we evaluate the benefit >> differently, then the cost might be acceptable. > > True. Because the people who you are scaring from to eavesdrop the > communication already know how you want to process this...
Huh? > > To be clear... IF this approach wasn't public and not known, then you might > benefit from it but when something is public and known, what you would do as > an attacker? Do you still wait in a hope of receiving plain text information > or easily change your role to a resolver and receive information you want as > it is not hard to detect. > I have not seen information that suggests strongly deployed TLS (with a proper RNG) is broken by a passive observer. Do you have a citation handy? > So in long term there is no benefit to use encryption without authentication > in resolver scenario. > There is a benefit - it forces Eve to become Mallory. Mallory risks being caught red handed. > >> > What I tried to explain here is that an observer role doesn't make >> sense in resolver scenario. >> >> Except that we have an existence proof that it does. > > It really doesn't... at least in this scenario. Why? Because this approach > would be standard and well known... So, if anyone (or the whom you're > talking about) before played the observer role now they would change their > role because they are still interested to receive your data and your node is > unable to detect this interceptions since whatever resolver you use is valid > by your node either a fake resolver or a real resolver. > This is why authentication is important. If the authenticating and non-authenticating resolver behave the same way on the network, it will be very risky to tamper, even with a resolver that fails open. Paul - perhaps this suggests that all stub and recursive resolvers should log keying information, even if it isn't used for validation/authentication/etc? > >> > DNSSEC just came to this game when some folks say that DNSSEC can >> protect this and they only need encryption. >> >> If you had strong authentication of the resolver, then this would be >> true. Since TSIG (which I expect you remember) or SIG(0) can solve the >> authentication part, then in fact the only thing you would need _is_ >> encryption, and then you could rely on the DNSSEC piece as well. >> > > We already know the problem with those approaches and as you said brining > DNSSEC to this discussion doesn't make sense.. > The point is that this solves the confidentiality issues that DNSSEC doesn't solve. It should solve it but many DNSSEC folks refused to address this issue. There are a variety of reasons and this draft by Paul helps us to move past those previous decisions. All the best, Jacob _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
