Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

[Jacob Appelbaum <[e-mail]>]

On 8/20/14, Hosnieh Rafiee <[e-mail]> 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