Re: [dns-privacy] changing protocol vs. using existing mechanism

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Nov 14, 2014 at 10:42 AM, Hosnieh Rafiee
<[e-mail]> wrote:
> Hi,
>
> There is one question from folks. There are some existing approaches that does not change DNS protocol. There are also new proposal that needs change on DNS protocol.
>
> For example, my proposal, cga-tsig, does not change DNS protocol. So is there any decision for the scope of solution space?
>

I don't think anyone is actually proposing to change the DNS protocol.
PRIVATE-DNS doesn't. Paul's might but I don't think that makes a
difference.

Looks to me as if you don't quite understand what my proposal does, I
note the following statement in your draft:

https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-10#section-1.1.4.1

" Private DNS [private-dns] is one of privacy approaches that uses TLS
   and consider using JSON. To establish a secure communications, many
   messages needs to back and forth because the assumption is that a
   node itself needs to verify the TLS certificate."

No, that is not at all what is going on. PRIVATE-DNS consists of a
one-time device binding operation and that is the only part that
involves JSON or multiple round trips. DNS lookups are stateless,
single request packet, multiple response packet interactions.

" - Might not have good performance (number of messages exchanged to
   establish this secure communication)"

No, the performance os Private-DNS is optimal, there is no improvement
possible over one round trip with no public key operations (or other
CPU intensive operations) in the transaction loop.

" - IP spoofing and MITM might be possible only when there is no CA or
   predefined Trusted Anchors (TA) so that it makes it possible for an
   attacker intercepts this communication at the beginning of TLS
   establishment."

Obviously there needs to be some means of authenticating the service
or you could be permanently binding yourself to a MITM attacker. There
are two main choices:

1) For a public service then a WebPKI TLS certificate is probably the
best choice.

2) For an enterprise service in which the user is issued a one time
use PIN, the SXS-Connect protocol provides mutual authentication. So
the client is authenticated to the server and the server to the
client.

I have not fully considered the case in which the device does not have
a trust root built in for (2). This is important for cases such as a
constrained device that might have a ten year shelf life. I have a
possible solution but I have to verify it.


Since this is TLS we could use any server authentication mechanism
supported by TLS. For example DANE. But using DNSSEC to secure the DNS
client resolver binding gives us a circular dependency issue. It would
probably be better to use a direct trust model.