From nobody Mon Mar  3 00:44:21 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433CF1A07B0; Mon,  3 Mar 2014 00:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.922
X-Spam-Level: *
X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 s6Gv69eet5Wn; Mon,  3 Mar 2014 00:44:18 -0800 (PST)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D70BE1A0349; Mon,  3 Mar 2014 00:44:17 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id p61so1615219wes.39 for <multiple recipients>; Mon, 03 Mar 2014 00:44:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vTh3CaUsbb0W7dRAvzSQ/G8MrxxBnRtIlcLgV0bDEgU=; b=jv+7e9XVL4fiv2ni3ZVgn/hPu/RVx9TPDlwLOsDM3mHTxI1SAxWbVY2scWEOZdVMVM MzADc1VY4mlPt5Q+7f+7gFjWKqIXr9vjMacAohNc14V9jQKkghIIk+v8AKOojDXBHJ1M H7aGof96Mj4ro6c+5Gmmmqwne/iqE4BtNowNW7CuUgQJAlUr7JfD5sQWk42ElmwMUSZ+ Pw7oJMwa/fGyv27Zs0asXOKMQg44T9CGtSNIocnNQ+IZOgc7AOfk4SMumXUIQfKnC5Gg +HRCIXe3a/Ux7CyMSEGGIM2hTdLzsEZ0XngdIc3Bh7eVvk59Bo+UjZrT0eix5PxD/EzC Z+Kg==
MIME-Version: 1.0
X-Received: by 10.194.21.193 with SMTP id x1mr14998447wje.33.1393836254653; Mon, 03 Mar 2014 00:44:14 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Mon, 3 Mar 2014 00:44:14 -0800 (PST)
In-Reply-To: <002101cf3495$1ad2d570$50788050$@rozanak.com>
References: <002101cf3495$1ad2d570$50788050$@rozanak.com>
Date: Mon, 3 Mar 2014 08:44:14 +0000
X-Google-Sender-Auth: rX7TXwaDzh3J-MIR8RhJl1XmLvI
Message-ID: <CAJE_bqdFknJ7Dy9QUJaQUj9Ca40TM0jWCfGNNyUSEkF5d39Rqw@mail.gmail.com>
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@wide.ad.jp>
To: Hosnieh Rafiee <ietf@rozanak.com>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/zd6WMcV9cTm8hD5h6eT1Lf5GrsU
Cc: dnsop <DNSOP@ietf.org>, DNSEXT Group Working <dnsext@ietf.org>
Subject: Re: [dnsext] We want to have fruitful discussions - please review
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 08:44:19 -0000

I have one quick question for my own understanding:

At Fri, 28 Feb 2014 15:55:21 +0100,
"Hosnieh Rafiee" <ietf@rozanak.com> wrote:

> [...] For DNS resolver, it
> receives this IP address securely via the option in the router advertisement
> message.

So, the security of this approach relies on how securely the client
can get the resolver's address, e.g.,
- Using SEND for RAs with RFC 6106
- (If and when it's defined) Using public-key based DHCPv6
  authentication
And, to make this part secure, the client needs to get the router's
certification or the server's public key securely beforehand.

Is my understanding correct?

--
JINMEI, Tatuya


From nobody Mon Mar  3 01:14:31 2014
Return-Path: <ietf@rozanak.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DF81A0349; Mon,  3 Mar 2014 01:14:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level: 
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 IwmjREuC2KL7; Mon,  3 Mar 2014 01:14:11 -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 633DB1A09B7; Mon,  3 Mar 2014 01:14:11 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 77E6F23E2D59; Mon,  3 Mar 2014 09:14:07 +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 pG7cUBr69PLr; Mon,  3 Mar 2014 10:14:05 +0100 (CET)
Received: from kopoli (g226063187.adsl.alicedsl.de [92.226.63.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id D61D223E2D58; Mon,  3 Mar 2014 10:14:04 +0100 (CET)
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: =?gb2312?B?J8nxw/ffX9TVJw==?= <jinmei@wide.ad.jp>
References: <002101cf3495$1ad2d570$50788050$@rozanak.com> <CAJE_bqdFknJ7Dy9QUJaQUj9Ca40TM0jWCfGNNyUSEkF5d39Rqw@mail.gmail.com>
In-Reply-To: <CAJE_bqdFknJ7Dy9QUJaQUj9Ca40TM0jWCfGNNyUSEkF5d39Rqw@mail.gmail.com>
Date: Mon, 3 Mar 2014 10:14:03 +0100
Message-ID: <004601cf36c0$ec06e7d0$c414b770$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFEEoOGM85KTJERR1lopDpQwQOweAERl5Lnm9zL4aA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/EXsjC0OrzMi5yAEcLSp7qQ6XIc0
Cc: 'dnsop' <DNSOP@ietf.org>, 'DNSEXT Group Working' <dnsext@ietf.org>
Subject: Re: [dnsext] We want to have fruitful discussions - please review
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 09:14:17 -0000

Hi JINMEI,

Thanks for your question and review.

> > [...] For DNS resolver, it
> > receives this IP address securely via the option in the router
> > advertisement message.
>=20
> So, the security of this approach relies on how securely the client =
can
get the
> resolver's address, e.g.,
> - Using SEND for RAs with RFC 6106
> - (If and when it's defined) Using public-key based DHCPv6
>   authentication
> And, to make this part secure, the client needs to get the router's
certification
> or the server's public key securely beforehand.
>=20
> Is my understanding correct?

To some extend correct but not but it is not bound to that option. One
example is where you are in untrusted network like a Caf=A8=A6. We =
assume that
you cannot trust your router or the router does not support SeND and you
really want to ensure that MITM attack will not happen during browsing =
any
websites (like your bank or etc) then you can always set an IP address =
of a
trusted resolver yourself. One example can be the use of an IP address =
of
the google resolver or any other resolver that supports cga-tsig (it can =
be
your home resolver as well). Your node can verify that using CGA/or SSAS
algorithm.

I hope I could answer your question.=20
Smile,
Hosnieh




From nobody Mon Mar  3 01:23:50 2014
Return-Path: <ietf@rozanak.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D05D1A0BFF; Mon,  3 Mar 2014 01:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level: 
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 6x3N8UxOWKFt; Mon,  3 Mar 2014 01:23:42 -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 8579F1A0C25; Mon,  3 Mar 2014 01:23:42 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 5E3E023E2D59; Mon,  3 Mar 2014 09:23:39 +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 alDQhln6cjS1; Mon,  3 Mar 2014 10:23:37 +0100 (CET)
Received: from kopoli (g226063187.adsl.alicedsl.de [92.226.63.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 9995723E2D58; Mon,  3 Mar 2014 10:23:37 +0100 (CET)
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: =?gb2312?B?J8nxw/ffX9TVJw==?= <jinmei@wide.ad.jp>
References: <002101cf3495$1ad2d570$50788050$@rozanak.com> <CAJE_bqdFknJ7Dy9QUJaQUj9Ca40TM0jWCfGNNyUSEkF5d39Rqw@mail.gmail.com> <004601cf36c0$ec06e7d0$c414b770$@rozanak.com>
In-Reply-To: <004601cf36c0$ec06e7d0$c414b770$@rozanak.com>
Date: Mon, 3 Mar 2014 10:23:36 +0100
Message-ID: <004701cf36c2$416a13e0$c43e3ba0$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFEEoOGM85KTJERR1lopDpQwQOweAERl5LnAgHd3GybzMIYUA==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/gx8S1d57zE7wsyaIIVg3YvNHQvw
Cc: 'dnsop' <DNSOP@ietf.org>, 'DNSEXT Group Working' <dnsext@ietf.org>
Subject: Re: [dnsext] [DNSOP] We want to have fruitful discussions - please	review
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 09:23:44 -0000

Follow up,

The good thing about CGA-TSIG or using CGA or SSAS as the algorithm is =
that,
if you only know the IP address (set it manually for the first time or =
can
receive it from a secure way like you can trust your router). Then no =
need
for any check on the public key since there is binding between this =
public
key and the IP address. Not sure the chairs uploaded the slides. If so =
you
can find the scenarios there as well.

Thanks,
Hosnieh

=20
> Thanks for your question and review.
>=20
> > > [...] For DNS resolver, it
> > > receives this IP address securely via the option in the router
> > > advertisement message.
> >
> > So, the security of this approach relies on how securely the client
> > can
> get the
> > resolver's address, e.g.,
> > - Using SEND for RAs with RFC 6106
> > - (If and when it's defined) Using public-key based DHCPv6
> >   authentication
> > And, to make this part secure, the client needs to get the router's
> certification
> > or the server's public key securely beforehand.
> >
> > Is my understanding correct?
>=20
> To some extend correct but not but it is not bound to that option. One
> example is where you are in untrusted network like a Caf=A8=A6. We =
assume that
> you cannot trust your router or the router does not support SeND and =
you
> really want to ensure that MITM attack will not happen during browsing =
any
> websites (like your bank or etc) then you can always set an IP address =
of
a
> trusted resolver yourself. One example can be the use of an IP address =
of
the
> google resolver or any other resolver that supports cga-tsig (it can =
be
your
> home resolver as well). Your node can verify that using CGA/or SSAS
> algorithm.
>=20
> I hope I could answer your question.
> Smile,
> Hosnieh
>=20
>=20
>=20
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


From nobody Mon Mar  3 11:35:52 2014
Return-Path: <ietf@rozanak.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671001A00D7; Mon,  3 Mar 2014 11:35:47 -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 FBT5Nt2BvBCt; Mon,  3 Mar 2014 11:35:45 -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 5EE731A030D; Mon,  3 Mar 2014 11:35:45 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 121EE23E2D59; Mon,  3 Mar 2014 19:35:42 +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 EWQB3SCHfICr; Mon,  3 Mar 2014 20:35:40 +0100 (CET)
Received: from kopoli (g226063187.adsl.alicedsl.de [92.226.63.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 1168B23E2D58; Mon,  3 Mar 2014 20:35:40 +0100 (CET)
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: <DNSOP@ietf.org>, <dnsext@ietf.org>, <Int-area@ietf.org>
Date: Mon, 3 Mar 2014 20:35:38 +0100
Message-ID: <00a201cf3717$c16b6490$44422db0$@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: Ac83F74owTVGJeQTQyerKFVPi2+p0A==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/3xBs_ygPIBgJ_QFY7ofNYdSwX7I
Subject: [dnsext] please review - DNS data integrity and confidentiality
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 19:35:47 -0000

Dear All,

CGA-TSIG (http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig ) will be
presented as a last item of intarea (Session 2014-03-04 1300-1400: Viscount)

                    
          intarea WG Agenda
          IETF 89
          TUESDAY, March 4, 2014
          1300-1400 Tuesday Afternoon Session I


I ask you all, DNS experts, please review this draft and attend intarea
session (tomorrow , Tuesday, at 13:00 - 14:00). Even though you might have a
meeting, please try to attend the 15 last minutes of intarea since it will
be the last item that will be presented there. Please consider reviewing
this draft so that we have fruitful discussions :-)

          

For those who didn't read my long note:
The area that this draft covers

- secure authentication during different scenarios especially the
authentication of the resolvers, without extra efforts, and by the support
of this algorithm or during updating PTR or FQDN record in a secure manner.

- privacy and confidentiality: People in IETF are looking for a  solution
for confidentiality as I heard discussion in this group and application
area. This can be a solution for this. This is especially helpful in the
unsecure environment where you want to have a privacy while browsing
different websites. So you need to have a data encryption between the
resolver and your computer. What your computer need to know is only the IP
address of the resolver, CGA-TSIG handle the other parts. :-) 

The other use case for confidentiality is in a zone transfer scenario or
dynamic update. The data exchange between the master and slave should be
encrypted to keep these data from prying eyes.

So, this draft answers to the need of both data integrity and
confidentiality and prevent IP spoofing without extra effort.

Hope to see you all tomorrow :-)
Thanks,
Hosnieh



From nobody Tue Mar  4 06:07:17 2014
Return-Path: <cas@strotmann.de>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4FE1A014F for <dnsext@ietfa.amsl.com>; Tue,  4 Mar 2014 06:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.809
X-Spam-Level: 
X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6] autolearn=no
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 3lQuiU7OHyYT for <dnsext@ietfa.amsl.com>; Tue,  4 Mar 2014 06:07:14 -0800 (PST)
Received: from csgate3.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 084881A0128 for <dnsext@ietf.org>; Tue,  4 Mar 2014 06:07:13 -0800 (PST)
Received: from x40.home.strotmann.de (unknown [212.255.240.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by csgate3.strotmann.de (Postfix) with ESMTPSA id E5E5250EC; Tue,  4 Mar 2014 15:07:08 +0100 (CET)
Received: by x40.home.strotmann.de (Postfix, from userid 1000) id DB8CB23E7D8; Tue,  4 Mar 2014 15:07:08 +0100 (CET)
References: <00a201cf3717$c16b6490$44422db0$@rozanak.com>
User-agent: mu4e 0.9.9.6pre2; emacs 24.3.1
From: Carsten Strotmann <cas@strotmann.de>
To: Hosnieh Rafiee <ietf@rozanak.com>
In-reply-to: <00a201cf3717$c16b6490$44422db0$@rozanak.com>
Date: Tue, 04 Mar 2014 15:07:08 +0100
Message-ID: <87r46iys4z.fsf@x40.home.strotmann.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/xRTyyu_ysSSWja6cLkeL35g0G0A
Cc: dnsext@ietf.org
Subject: Re: [dnsext] please review - DNS data integrity and confidentiality
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 14:07:16 -0000

Hello Hosnieh,

(I've only responding on DNSEXT, if one of the other lists is more
approriate, let me know).

Hosnieh Rafiee <ietf@rozanak.com> writes:

>
> CGA-TSIG (http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig ) will be

I've read your draft and attended the INTAREA session today. I'm at this
moment have not a full understanding of the concept, but it is
interesting and there is some need.

Some questions:

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)?

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

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

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

Best regards

Carsten Strotmann

-- 
Sent with my mu4e


From nobody Tue Mar  4 06:29:55 2014
Return-Path: <ietf@rozanak.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6405D1A0119; Tue,  4 Mar 2014 06:29:54 -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 sTrXL_sky3_p; Tue,  4 Mar 2014 06:29:53 -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 415B41A0167; Tue,  4 Mar 2014 06:29:53 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 98B1023E2D59; Tue,  4 Mar 2014 14:29:49 +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 MR7lsVr8IbAc; Tue,  4 Mar 2014 15:29:48 +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 CBCEC23E2D58; Tue,  4 Mar 2014 15:29:48 +0100 (CET)
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: <Int-area@ietf.org>, <dnsext@ietf.org>, <DNSOP@ietf.org>
Date: Tue, 4 Mar 2014 15:29:47 +0100
Message-ID: <020f01cf37b6$31cd2fe0$95678fa0$@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: Ac83tjA0Y6n8lEXPRh2RkcSJ7YriDg==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/2YY7Pjim0mwuScH6fKD5mYt1I60
Subject: [dnsext] Please submit your questions about cga-tsig to mailing list
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 14:29:54 -0000

Just a two remarks or highlights about the presentation:
-  Data confidentiality can also be used in the resolver scenario the same
way as zone transfer scenario that is explained during presentation as an
example scenario. 
- The proof of concept or implementation in NL Net labs is only available
for resolver scenario as I also explained in my previous messages to the
mailing list everytime I discussed about the implementation
But the early versions of this draft was implemented for powerDNS (as a
proof of concepts)
- This draft does not only works in cases where SeND is available but as
also Erik mentioned, it works when you generate your CGA address and assign
it like a static address.

Thank you,
Best,
Hosnieh 


From nobody Tue Mar  4 13:56:26 2014
Return-Path: <ietf@rozanak.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@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/dnsext/CeuPpHMFgz2dsBFtvbiqHMzaio0
Cc: DNSOP@ietf.org, Int-area@ietf.org, dnsext@ietf.org
Subject: Re: [dnsext] please review - DNS data integrity and confidentiality
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-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


From nobody Wed Mar 19 09:20:22 2014
Return-Path: <marka@isc.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3851A07B1 for <dnsext@ietfa.amsl.com>; Wed, 19 Mar 2014 09:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.049
X-Spam-Level: 
X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 4-2AhgTuhim9 for <dnsext@ietfa.amsl.com>; Wed, 19 Mar 2014 09:20:17 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8011A07C7 for <dnsext@ietf.org>; Wed, 19 Mar 2014 09:20:14 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B5A3CC9505 for <dnsext@ietf.org>; Wed, 19 Mar 2014 16:19:52 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1395246005; bh=h0T6PPLLvVtzu+4nwXG/Xf7PXgIa8kwhy1OhphKiMmU=; h=To:From:Subject:Date; b=BCdgt0V4hObS/ecH4cdTGqDmzls4S4xYXFyZrLf20Um/9D1TA62ziM2kxmdQJQjU4 xmSHDTc/papkDiR16QWZAqQwejOertYRIZNCl7Ts+PrjZWfimEkggq57Mqy/pGskJJ 6NpPBp01IK+du1P6Pf3pBvuffcsjNkoRnY8OCsyw=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for <dnsext@ietf.org>; Wed, 19 Mar 2014 16:19:52 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DBA12160066 for <dnsext@ietf.org>; Wed, 19 Mar 2014 16:20:57 +0000 (UTC)
Received: from rock.dv.isc.org (unknown [149.20.50.236]) by zmx1.isc.org (Postfix) with ESMTPSA id D994F160051 for <dnsext@ietf.org>; Wed, 19 Mar 2014 16:20:57 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 91B77119CCAF for <dnsext@ietf.org>; Thu, 20 Mar 2014 03:19:53 +1100 (EST)
To: dnsext@ietf.org
From: Mark Andrews <marka@isc.org>
Date: Thu, 20 Mar 2014 03:19:53 +1100
Message-Id: <20140319161953.91B77119CCAF@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/sfiO1BNKwe61udv2-zEdmT0FSrY
Subject: [dnsext] BADVERS returned for unknown EDNS option
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 16:20:19 -0000

	Is the vendor of the nameservers cpb.gov are runnning willing
	to standup and issue a recall notice for the version they
	are running.  version.bind returns "3.2.2" 

	When presented a unknown EDNS option they return BADVERS
	rather then ignoring the option.  The EDNS RFCs (both the
	original and the replacement) are explict about what
	conditions set BADVERS.

	This sort of mis-behaviour make it very difficult to deploy
	new EDNS options.

	Mark

; <<>> DiG 9.10.0b2 <<>> @sauthns1.qwest.net cpb.gov +nsid
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39491
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cpb.gov.			IN	A

;; Query time: 12 msec
;; SERVER: 2001:428::7#53(2001:428::7)
;; WHEN: Thu Mar 20 03:14:22 EST 2014
;; MSG SIZE  rcvd: 36


; <<>> DiG 9.10.0b2 <<>> @sauthns1.qwest.net cpb.gov +sit
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 57276
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 12 msec
;; SERVER: 2001:428::7#53(2001:428::7)
;; WHEN: Thu Mar 20 03:15:32 EST 2014
;; MSG SIZE  rcvd: 23

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka@isc.org