Subject: [DNSOP] please review CGA-TSIG

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 25 Jun 2014 23:04:51 +0200

Hello,

We actually put all our efforts to change the document thoroughly and not
only consider the IPv4 scenario that was comment of some people in
mailinglist but also we expand the DNS privacy section and explained it in
more detail (no need to change the protocol.)
      http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-08

So, any more comments? Any more feedback?  do you think it is now a good
acceptable version?   :-) 

Best,
Hosnieh

---

From: Paul Vixie <[email-masked]>
Date: Thu, 26 Jun 2014 01:46:50 -0700

>       http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-08

thank you. i am not a member of the int-area@ mailing list, so please
forward this reply to that forum.

> So, any more comments? Any more feedback?  do you think it is now a good

see below.

> The TSIG keys, which are manually
>    exchanged between a group of hosts, need to be maintained in a secure
>    manner.

tsig keys have no needs. i suggest "must be maintained" here.

> or to assure a Slave Server that the zone transfer is from
>    the original Master Server and that it has not been corrupted.

or as an access control method to permit AXFR/IXFR only when a shared
TSIG key is present.

> Handling this shared secret in a secure manner and exchanging it does
>    not appear to be easy. This is especially true if the IP addresses
>    are dynamic or the shared secret is exposed to the attacker.

this is nonsequitur. either give a reference for what "does not appear
to be" observed, or simply note that out of band key exchange by
sneaker-net does not scale and was never expected to. also, _what_ ip
addresses? you've not introduced that concept before referencing it.

> this document proposes two
>    algorithms which support both IPv4 and IPv6 scenarios.

does each of the two support both protocols? if not, the above wording
is wrong. perhaps you mean "two algorithms, one for IPv4, and one for IPv6."

> This document updates the
>    following sections in TSIG document: ...

those details should not be in the Introduction section.

> There are several different methods where DNS records can become
>    compromised. Some examples of methods are DNS Spoofing; DNS
>    Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS
>    Update; User Privacy Attack; and Human Intervention.

this Problem Statement is grossly inadequate to motivate the proposal
you've submitted.

consider the User Privacy Attack scenario. the thing that you'd like to
hide is the q-tuple, since the response is public information. only the
requester's interest in a particular q-tuple at a particular time is
worth protecting. we end up having to encrypt the response not because
the response itself is sensitive but because a response will implicate a
q-tuple which is sensitive.

in the stub-to-recursive data path, existing data mining is not occuring
in-channel, but at the endpoints. A/V products instrument end-system
resolvers to learn and sometimes intercept or redirect DNS transactions.
that isn't a problem -- users who don't want it to happen can't stop it
with encryption, but they can stop it by uninstalling the A/V. at the
other end, an RDNS often participates in some kind of passive DNS
collection effort for security analytics purposes, and that is again not
the problem being stated here -- because that's happening outside the
channel where encryption would do any good. asking for dns path
protection end-to-end from stub to authority, such that the RDNS did not
know the q-tuple, raises the questions of how could it cache or reuse
anything, how could DNS function without caching and reuse, and how
could the RDNS route a query to an ADNS without knowing the q-name.

yet you're proposing hop-by-hop channel encryption. there is no stated
justification for who that helps or how. only if a user wants to use a
distant RDNS like opendns or googledns would a form of channel
encryption that prevented the user's ISP and other intervening ISP's (or
national security agencies in the wide-area data path) be useful. if
that's the value you intend to add then you should say so -- after
contextualizing it and defining your taxonomy.

>    Disadvantages:
>
>    - Offline generation of the signature
>
>    DNSSEC [RFC6840 <http://tools.ietf.org/html/rfc6840>] needs manual step for the configuration. For
>    instance, when a DNSSEC needs to sign the zone offline.

offline generation is not a disadvantage. dnssec makes it optional, and
offers it because it is a desirable feature.

moreover you appear not to know about SIG(0) which worries me since that
ought to have been part of any reasonable background check on this topic
before writing a proposal as fundamental as this one.

>    - IP spoofing
>
>    The public key verification in DNSSEC creates a chicken-and- egg
>    situation. In other words, the key for verifying messages should be
>    obtained from the DNSSEC server itself. This is why a query requester
>    needs to verify the key.
>
>    If this does not happen, DNSSEC is vulnerable to an IP spoofing
>    attack.

this is completely wrong, as in, 100% counter-factual.

i stopped reading this draft at the end of section 1. it appears not to
be worth my time to read the rest of it. i am frankly astonished that
anyone would produce text and ideas at this low quality level and then
ask others to review it with the invitation: "do you think it is now a
good acceptable version?" my answer is not just "no" or "of course not"
but rather "you should know better than to ask, given the document as it
is."

vixie