Re: [DNSOP] [dnsext] please review - DNS data integrity and confidentiality

"Hosnieh Rafiee" <ietf@rozanak.com> Tue, 04 March 2014 21:56 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0715A1A02B3; Tue, 4 Mar 2014 13:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8h_lly5uKMD; Tue, 4 Mar 2014 13:56:21 -0800 (PST)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id D2CA91A0139; Tue, 4 Mar 2014 13:56:20 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 02D4423E2D59; Tue, 4 Mar 2014 21:56:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiLBKeU2PRw6; Tue, 4 Mar 2014 22:56:15 +0100 (CET)
Received: from kopoli (g225059012.adsl.alicedsl.de [92.225.59.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 155D723E2D58; Tue, 4 Mar 2014 22:56:15 +0100 (CET)
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: "'Carsten Strotmann'" <cas@strotmann.de>
References: <00a201cf3717$c16b6490$44422db0$@rozanak.com> <87r46iys4z.fsf@x40.home.strotmann.de>
In-Reply-To: <87r46iys4z.fsf@x40.home.strotmann.de>
Date: Tue, 4 Mar 2014 22:56:13 +0100
Message-ID: <02de01cf37f4$8fc39060$af4ab120$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGVR1H6RkkJ/3Y7ghSqydMtFggWnwHxi2DemzWFJjA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/Dbb-T4EZUQB9xuNYKmHMTTTj0w4
Cc: DNSOP@ietf.org, Int-area@ietf.org, dnsext@ietf.org
Subject: Re: [DNSOP] [dnsext] please review - DNS data integrity and confidentiality
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 21:56:24 -0000

Hi Carsten,

Thanks a lot for your comments. Please find my answer as follows

> 11.1 Generation of secret key (Page 17)
> 
> > It is possible to use the current DNSKEY RR (RFC 3757) to send the
> > public key of the DNS server.
> My understanding of the DNSKEY RR is that (at least in the context of
> DNSSEC) the DNSKEY RR is bound to a specific DNS zone, but not to a DNS
> server. The draft indicates that the DNSKEY is somehow used to
> identify/authenticate the DNS server. Which DNSKEY record would that be
> (out of which zone)?

The encrypted secret key is sent to the other node in TSIG RR in a same
packet that CGA-TSIG is sent. So, there is no need for extra packet for
sending the secret key. But for key exchange (in the confidentiality
scenario), there is a need to send public key so that the other node can
encrypt this secret key.  I thought to use TKEY (which is not related to
DNSSEC but related to TSIG) but as you mentioned about DNSKEY (The draft
does not talk about this option), there is a need to modify TKEY RR  to
adapt to CGA-TSIG. So, I guess the best option here is something like the
following scenario to avoid any changes to DNS RRs

Node A wants to ask node B for its public key. Node A includes TSIG RR with
the algorithm set to CGA-TSIGe and set the CGA-TSIG data length to zero.
Node B receives this packet and check the algorithm type. Because it is
CGA-TSIGe (CGA-TSIG with encryption), it does not assume to find any query
or update in the DNS packet and consider this packet as asking for its
public key.  Node B, includes his public key in CGA-TSIG data structure of
the packet and set the algorithm type to CGA-TSIGe. Node A receives this
packet, since it was the answer to his own key request, it retrieves the
public key of Node B from CGA-TSIG data structure, generates a secret key,
encrypts this secret key with node B public key and encrypt the whole query
request with this secret key and sign these messages with its own private
key and include its own publickey and other CGA parameters in CGA-TSIG and
sends this message to Node B. Node B Receives this message and process the
verifications and decrypt the packet.

So, in this case we no longer need to use any TKEY in first step as well.

Any thought?

 > > It encrypts this
> >   secret key using the DNS server public key. This allows only the DNS
> >   server to decrypt this secret key.
> 
> This implies some private key being online on the DNS server. Which
private
> key would that be?

No it is not a private key. It uses different algorithm and it is only a
random number that generates by Node A. However, Node A uses this value and
AES algorithm (or any other symmetric algorithm) to encrypt the DNS message
and put it back in the DNS sections (update,  prerequisite, etc)

> 11.2 DNS message generation (Page 17)
> 
> > The node MUST encrypt all DNS message sections that required
> >   protections using the secret key generated in last section and AES
> >   symmetric algorithm.
> 
> It is probably not good to hardcode an particular cipher algorithm (AES).

Right. I need to consider an algorithm type in CGA-TSIG data structure for
symmetric algorithm. I will include it to the draft.

> Probably more questions will come up once I read the draft again and work
> with the proof-of-concept implementation.


Thank you again,
Best,
Hosnieh