Subject: [Int-area] 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: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 26 Jun 2014 22:50:48 +0200

I'm just forwarding Vixie's message. Since some folks in intarea are not the
member of DNSOP.

Thank you,
Best,
Hosnieh
----------------------------------------------------------------------------
------------

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

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] 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

---

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

see below.

>    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.

>    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.

>    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."

>    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.

>    DNSSEC [RFC6840 <http://tools.ietf.org/html/rfc6840>] needs manual step for the configuration. For

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