And there is also public key rolling issue in this scheme just as the zone KSK
rolling in DNSSEC. More consideration is needed to handle this issue since the
private key of a DNS domain may be leaked.
Guangqing Deng
CNNIC
From: Marc Lampo
Date: 2013-11-29 18:53
To: W.C.A. Wijngaards
CC: dnsop@ietf.org WG
Subject: Re: [DNSOP] confidentialdns draft
I think the draft is very unclear on this (DNSSEC) point -
at least I don't find this statement about the ENCRYPT RR being signed by
with the private key of example.com.
Anyway : a RRSIG RR holds the name of the domain that signed in clear text.
Kind regards,
Marc
On Fri, Nov 29, 2013 at 10:40 AM, W.C.A. Wijngaards <wou...@nlnetlabs.nl> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Marc,
In the draft it says to store the ENCRYPT RR in this case at
ns.example.com. It would then be signed with the ZSK DNSKEY for
example.com, with normal DNSSEC chain of trust.
But again, the authenticated operation is not the main aim of this draft.
Best regards,
Wouter
On 11/29/2013 10:28 AM, Marc Lampo wrote:
> Hello,
>
> (a reaction on second paragraph of 4. Authenticated Operation,
> only)
>
> That paragraph states that the ENCRYPT RR can be signed by DNSSEC.
> However, I don't think is possible !
>
> A signature is the hash of DNS-data-sent, encrypted with the
> private key. But in this case : private key of who ? !!! not the
> root-zone, I hope. ? from the domain one is about to sent a query
> for (but the whole idea is to hide that kind of information !)
>
> But since this encryption is really between a DNS client and the
> DNS server it is about to query, it should be the "private key of
> that DNS server". But that is not what DNSSEC is about.
>
> Hence, I think ENCRYPT RR's cannot be protected by DNSSEC.
>
> Kind regards,
>
> Marc
>
>
> On Thu, Nov 28, 2013 at 2:25 PM, W.C.A. Wijngaards
> <wou...@nlnetlabs.nl <mailto:wou...@nlnetlabs.nl>> wrote:
>
> Hi,
>
> I also heard that this is the place to discuss DNS privacy.
>
> This draft is a protocol, and represents an (interesting) point in
> the solution space. I would refer to Borzmeyer's draft and Koch's
> draft for problem space analysis.
>
> http://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-00
>
> It supports opportunistic encryption, i.e. try to encrypt but
> fallback to insecure. This supports deployment immensely, because
> clean DNS paths are uncommon.
>
> It supports stateless operation. It uses UDP.
>
> It supports encryption for stub-to-cache and cache-to-authority.
>
> Best regards, Wouter
>
> _______________________________________________ DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSmGEgAAoJEJ9vHC1+BF+NM2MP/3eUycaHd5l3eywpaevDj9HX
z1E7b3+ebH/cLGMAR0KD940aYw7xYlDG/6b83hqeEVdQVxD7ga6VUcOPImbfOX7o
h8AwJif9mFsGaPCFwxMiaGnF/NmdPAt+C9KNB9fNuEKWIGZbNCDjms7KpC6FDTua
JJ6lPLnuuWCiIUEiKbsjOEl2sJ2y8XV48+jvKuYYXc3EOL2tF0+/BiclXSB7Jw3y
YZ9caUU24teNVWU6g24SflxX/WdPRdSGAGFLYmFc2NEWrrXVvhmpmVGl9le/W6Lc
/pycV+yQZEK7NXP1KrAx28GSjlaJ8duKAXgAk8zsw7bEiqMPpzzNx7fp9pkXGbRy
KoEKMiOdnZGnqhIAx4H32ookjWuMnZFGY2FeKL0D3YsR9AgkuVbc+ga7MODwg6JH
62WADFn8DZCzbNOGIc7375FiVpogCZfPOP5BjrN1VTWL6r3jxAClWZABhQ+gEfCt
34+cxl83FaznxkvhK5DBQoQQmVdcitKOywkKgTlCPAd+gXSJ7SzzxrlcC5Vz0Py5
xoRYjPOnFC/Fz3rrLzhFomsISftKeIsvuCRlqsnd/FMzkqwxhUtZuKlUYEJs5qbF
kxv39xcDrAlbpyYvK5o14LKzto9+7/zpWI/js/0A1gWaq62mbpoq67J+UbgYCASk
Ilm/xu2QrnoGLsAS9R3q
=8SfA
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
