Subject: [Int-area] comments on draft-rafiee-intarea-cga-tsig-07

From: 神明達哉 <[email-masked]>
Date: Tue, 4 Mar 2014 13:13:40 +0000

On top of a preliminary Q&A at the dnsop/dnsext lists
(http://www.ietf.org/mail-archive/web/dnsop/current/msg11252.html)
here are a bit more detailed comments on the draft of mine.

Overall, the advantage of this approach doesn't seem to be very
convincing to me:
- It's IPv6 only.  While I'm a strong lover of IPv6, it's not
  realistic (or efficient) to consider a solution for DNS security
  that doesn't work for IPv4.
- At least to me, the traditional TSIG would be sufficient to protect
  zone transfers.  Usually we expect cooperation between primary and
  secondary servers (they are often even the same administrator), so
  it doesn't have to be public key based mechanism.
- To protect dynamic updates, my general understanding is that the
  major barrier is not the underlying authentication mechanism but
  that many server administrators simply don't want to allow their
  clients to update the zone.  When the administrator can accept that
  operation, and it's only for AAAA or PTR, I guess they would even
  accept weaker but more easier to use mechanisms such as BIND 9's
  "tcp-self" update-policy (yes, this is a hack and not really secure
  for security purists, but doesn't require any protocol
  modification).
- To protect query/response exchanges between a stub and a recursive
  server, cga-tsig still requires some manual setup, whether it's a
  public key/certificate of the router or DHCPv6 server, or manual
  installation of the recursive server address (see the email thread).
  Then it doesn't seem to be very advantageous compared to SIG(0).
- For confidentiality, CGA-TSIGe may or may not be a better approach
  than other known candidate solutions (I've simply not fully
  understood all pros and cons among the possible solutions).  One
  thing I've noticed is that if the server's public key is published
  in the form of DNSKEY, we might simply use the DNSSEC infrastructure
  to validate the key (I understand the corresponding zone may not
  always be signed and/or possible to validate).

There may be some specific niche cases where cga-tsig is really
advantageous than other alternatives, but as a general mechanism it
doesn't seem to be attractive enough to justify the introduction of
new protocol and the disadvantage of not supporting IPv4.

Some specific comments on the draft:

- In section 1.1, second paragraph:

   If DNSSEC (RFC 6840) or TSIG, as a security mechanism is in use, then
   the problem would be the manual step required for the configuration.
   For instance, when a DNSSEC needs to sign the zone offline. The
   public key verification in DNSSEC creates chicken and eggs situation.
   In other words, the key for verifying messages should be obtained
   from DNSSEC server itself. This is why the query requestor needed to
   ask other DNS servers up to top level in root to be able to verify
   the key. If this does not happen, DNSSEC is vulnerable to IP spoofing
   attack. This problem could easily be handled by the use of CGA-TSIG
   as a means of providing the proof of IP address ownership.

 I don't understand what this paragraph tries to claim.  If the
 "problem" is that the validator needs to somehow install some trust
 anchor (usually at the root zone and with some manual operation)
 securely, that's certainly an operational issue.  But I don't
 understand how CGA-TSIG could solve this.  Whatever it means, we
 still need to get the server's address securely, so it seems to
 simply shift the need for setup somewhere to the need for setup
 somewhere else.

- In Section 5, it uses the term "DNS update (message)" in many places
  in the context of zone transfer.  example:

   [...] When the DNS update message is processed, the slave DNS
   server can authenticate the master DNS server based on the source IP
   address and then, prove the ownership of this address by use of the
   CGA-TSIG option from the TSIG RR.

  I suspect these "update" should actually be [AI]XFR.

- In section 11.2:

   [...] It excludes TSIG RDATA (That usually added in
   the additional section of the DNS messages) from the encryption text.

  A TSIG RR must "always" be in the additional section, not just
  "usually" per RFC2845.

- In section 11.2:

   The node MUST encrypt all DNS message sections that required
   protections using the secret key generated in last section and AES
   symmetric algorithm. It excludes TSIG RDATA (That usually added in
   the additional section of the DNS messages) from the encryption text.

  Does this mean, for example, the encrypted message contains some
  encrypted data (maybe encrypted header, question, answer, authority
  sections) followed by the additional section in plain text?  If so,
  how can we decrypt it as described in Section 11.4?

   The DNS server retrieves the secret key from MAC field. It then
   decrypts this secret key using its own private key.

  If some or all of the preceding sections are encrypted, the
  receiving server cannot even identify the location of the additional
  section, where the TSGI RR is located.  This can be addressed with
  some minor extension, but it's not clear from the draft, and if it
  wants to be an interoperable specification, such details are
  crucial.

--
JINMEI, Tatuya

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 4 Mar 2014 14:49:41 +0100

Hi ,

> Overall, the advantage of this approach doesn't seem to be very convincing
to
> me:

I am also thinking about expanding it for IPv4. One possible solution is
using the mapping of IPv4 and IPv6. It means use the hash of public key the
same way as we use in IPv6 for IPv4. It will not have the same security as
exist for IPv4 but is securer than many current approaches for IPv4. 
 However, I am not quite agree with this point because we are in transition
time. All networks needs to support both, that is true but there is only
some mechanisms that works in both cases and in most cases there is a
separate policies for the use in IPv4 and IPv6. This is what can consider
here too. Since I do not think the node asks at the same time both IPv4 and
IPv6, Does it? So, if it is IPv4, one can use any available mechanism in
IPv4 and if it is IPv6, then it can answer it. Again, that mapping can also
solve this problem  

>   it doesn't have to be public key based mechanism.

The traditional TSIG has some problems that I explained in problem statement
of this document. Such as manually exchange of a shared secret and in case
of shared secret exposal to the attacker, the repeat of this process. It
also does not provide data confidentiality that this draft have this
advantage that provide this option easily without extra effort.
Public key mechanisms are not so heavy performance. I tested them. It is
heavy performance if you want to encrypt or decrypt a large data with them.
And here we don't do this. Signing a message is the process of hashing a
data and then encrypting the hash of data. 

>   for security purists, but doesn't require any protocol

This document does not change protocol . This is why we added all values in
the other data section of TSIG.  I guess you misunderstood the problem here.
IMHO, what you exclaim here is that we don't need security because we don't
want to modify protocol. This is quite a wrong consideration. What I
understand here, the whole process in IETF is toward having better support
of security and privacy, both.
Now again, the problem that this draft address is not only authentication,
again as I explained earlier, it is the problem of IP spoofing during DNS
update. 
In draft I explained two different scenarios. Zone transfer is different
than only letting the client to update his own values like his PTR. You are
right that you might not let any client to update any records, but some
administrator wants to let their clients to do so because the applications
working based on the names not IP. 

For zone transfer process I considered both  data confidentiality and data
integrity and secure authentication. How you can have this with tcp-self?
You cannot. 

I will continue answering the other parts of your comments after DNSE today.
Thank you,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 4 Mar 2014 23:49:40 +0100

Hi again,

Thanks again for your comments. I just continue answering from where I
stopped. 

> convincing
to

I am also thinking about expanding it for IPv4. One possible solution is
using the mapping of IPv4 and IPv6. It means use the hash of public key the
same way as we use in IPv6 for IPv4. It will not have the same security as
exist for IPv6 but it is securer than many current approaches for IPv4. 
 However, I am not quite agree with your point because we are in transition
time. It is true that all networks needs to support both IPv4 and IPv6 but
there is only some mechanisms that works in both cases. Often, there is a
separate policies for the use in IPv4 and IPv6. This is what can be
considered here too. Since I do not think the node asks at the same time
both IPv4 and IPv6, Does it? So, if it is IPv4, one can use any available
mechanism in
IPv4 and if it is IPv6, then it can answer use CGA-TSIG. Again, that mapping
can also solve this problem. 

<snip>

>  I don't understand what this paragraph tries to claim.  If the  "problem"
is that
> the validator needs to somehow install some trust  anchor (usually at the
root
> zone and with some manual operation)  securely, that's certainly an
> operational issue.  But I don't  understand how CGA-TSIG could solve this.
> Whatever it means, we  still need to get the server's address securely, so
it
> seems to  simply shift the need for setup somewhere to the need for setup
> somewhere else.

This paragraph explains that neither DNSSEC nor TSIG can avoid IP spoofing.
DNSSEC only can avoid it if a node checks the keys up to the root level in a
chain of TAs. Also it explains that for every configuration of TSIG, one
needs a manual step while CGA-TSIG eliminates  this manual step. 
As explained in the draft, in zone transfer scenario, one only needs to add
the IP address of the authorized zone updater to the zone file. If any of
those authorize updater changes its IP address, CGA-TSIG handle this process
and no further process is needed. No administrator allows zone transfer from
anonymous updater and they need to set up a trust. 

This drafts also explains other scenarios such as a resolver scenario. This
part is what DNSSEC also cannot address it at the moment because the
resolver needs to response to anonymous queries. So, there are many
questions such as how to do the key exchange of the resolver with anonymous
nodes all over the internet. Neither DNSSEC nor TSIG provides the data
confidentiality but CGA-TSIG can provide this the same way that can provide
the data integrity. It is not as complicated as if it wants to handle in
other protocols.

So it is not only decreasing the administration process or I call it human
intervention (human intervention is a well-known attacks and open the doors
to new attacks on DNS servers) but also several other observations that the
current protocols are not able to handle it or cannot handle it with a few
efforts. 

>   I suspect these "update" should actually be [AI]XFR.

IMHO, this is a mechanism or an approach to update a zone file. What I meant
in the document is to update a zone file and not different what mechanism is
in use either the node wants to use incremental update or the other
approach. This is why I used "update" word and not [AI]XFR. IF DNS people
thinks it is better to use that word, then I just follow.

Any thought?

>   A TSIG RR must "always" be in the additional section, not just

I guess, here is misunderstanding of the meaning. What I meant here is that
the DNS server does not always include TSIG RRs to DNS messages if there is
no security in use.

I will remove "usually" and will not add any other words to avoid any
misinterpretations. 

>   how can we decrypt it as described in Section 11.4?

Yes, with the secret key and the use of symmetric algorithm, the values that
the verifier nodes can obtain from the MAC section of the TSIG RR when the
algorithm type is CGA-TSIGe

>   wants to be an interoperable specification, such details are

The types section is not encrypted. Only the content of each section are
encrypted. 
So for instance
Type|length|reserve|  no encryption but other parts encrypted except
additional section

I will clarify this in the new version. 
Thanks again,
Best,
Hosnieh

---

From: 神明達哉 <[email-masked]>
Date: Wed, 12 Mar 2014 08:49:30 -0700

At Tue, 4 Mar 2014 23:49:40 +0100,

> Thanks again for your comments. I just continue answering from where I

For a higher level points, it looks like we simply have to agree to
disagree.  I have no particular incentive to convince you on my view
(and you don't necessarily have to convince me to get the proposal

> thinks it is better to use that word, then I just follow.

At least "update" is very confusing to me as it can be easily confused
with dynamic DNS updates.  It doesn't have to be "[AI]XFR", but at
least I'd avoid the word "update" in this context.

> the DNS server does not always include TSIG RRs to DNS messages if there is

Ah, okay.  I misunderstood the meaning.

> I will remove "usually" and will not add any other words to avoid any

This works for me.

> > - In section 11.2:
[...]
> Type|length|reserve|  no encryption but other parts encrypted except

I'm afraid I don't understand this.  I don't even understand what
"types section" means.  Maybe a detailed format of the message to be
decrypted in Section 11.4 will help.

--
JINMEI, Tatuya

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 12 Mar 2014 18:35:29 +0100

Hi JINMEI,

Thanks again for your comments.

> For a higher level points, it looks like we simply have to agree to
disagree.  I
> have no particular incentive to convince you on my view (and you don't
> necessarily have to convince me to get the proposal adopted), so I'll only
> answer specific points of the draft content:

My job here is to accept most useful comments that can improve the draft and
I welcome them. 
As I understand from your last messages, you concerns about the cases that
this proposal does not support IPv4. Now it does.. but I only need to
re-organize the draft and include it.
http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-2.pdf
This might help until I submit the revised version.

> > IMHO, this is a mechanism or an approach to update a zone file. What I
> > meant in the document is to update a zone file and not different what
> > mechanism is in use either the node wants to use incremental update or
> > the other approach. This is why I used "update" word and not [AI]XFR.
> > IF DNS people thinks it is better to use that word, then I just follow.
> >
> > Any thought?
> 
with
> dynamic DNS updates.  It doesn't have to be "[AI]XFR", but at least I'd
avoid the
> word "update" in this context.

Ok, if you think it is confusing, in parenthesis I will add "[AI]XFR"

> > The types section is not encrypted. Only the content of each section
> > are encrypted.
> > So for instance
> I'm afraid I don't understand this.  I don't even understand what "types
> section" means.  Maybe a detailed format of the message to be decrypted in
> Section 11.4 will help.

I will add picture to upcoming version. This might help.

Thanks,
Best,
Hosnieh