IETF Logo Mail Archive

[dns-privacy] Considering DHCP

Linhui Sun <lh.sunlinh@gmail.com> Tue, 14 April 2015 09:46 UTC

Return-Path: <lh.sunlinh@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749551A2119 for <dns-privacy@ietfa.amsl.com>; Tue, 14 Apr 2015 02:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 eazOeu3Fb5tR for <dns-privacy@ietfa.amsl.com>; Tue, 14 Apr 2015 02:46:20 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681A81A1F02 for <dns-privacy@ietf.org>; Tue, 14 Apr 2015 02:46:20 -0700 (PDT)
Received: by qku63 with SMTP id 63so8792113qku.3 for <dns-privacy@ietf.org>; Tue, 14 Apr 2015 02:46:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=iLEwzAdPU1wv2qVNXC+vDyLhbi0uFasxHj3LqpRw4Mo=; b=oVtKPxUrOptp496hgBxjLvvoPuayfKDKu6ZNldE0A+tf/CRhSW4ouunSm/Aa0arYah UTPq+hrVwRzzj11C9PeE6SyQX+hI5SMgdEp2u3GR3OPm0wGQslcy3UmPtx5QZ/YyfuPA ptiQ2bSqzRiryAuxzqfieEUgKRl7dkZXI4bugQapvI91u26pvXAbNuHDAeOOF41EA+3x UF6/Jhk8edOhajNTOiCGJB+nRiUw3WHNLk3CiWUks1MZd1M4T/X+w/EHtqg7q13DYY/w MaCYVsC7x5AXmbwfpqlj2gTGFQLqiNTxkwWJI/1FmGSzl7kr2WGbPE8ZxQag3HZ/Jr2s bvQw==
X-Received: by 10.140.237.72 with SMTP id i69mr21823329qhc.35.1429004776439; Tue, 14 Apr 2015 02:46:16 -0700 (PDT)
Received: from [127.0.0.1] (ec2-54-210-254-229.compute-1.amazonaws.com. [54.210.254.229]) by mx.google.com with ESMTPSA id s7sm300168qgd.4.2015.04.14.02.46.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 02:46:15 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14290047744600.92389060347341"
From: Linhui Sun <lh.sunlinh@gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In-Reply-To: <87bnirs4vs.fsf@alice.fifthhorseman.net>
References: <CADZyTkkiOVimmg3MzSs1+u4reDXskd78K3nMHtKU+MD6NCox-Q@mail.gmail.com> <201504140903058468192@cnnic.cn> <alpine.LFD.2.10.1504132301570.15124@bofh.nohats.ca> <201504141202242629189@cnnic.cn> <87bnirs4vs.fsf@alice.fifthhorseman.net>
Date: Tue, 14 Apr 2015 17:46:12 +0800
X-Cm-Message-Id: 1429004774358289d451c00ec236cac5cee543c8f59d6438552ce1e6578411719547150
X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0MjkwMDQ3NzIwMDAiLCJjIiwiMTQ5ODM4NzIyMTg0MzA2NTMzMSIsInYiLDFd
X-Mailer: CloudMagic
Message-Id: <1429004774927-6c580df8-a4db7bb6-ea35c9a1@gmail.com>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/0Jn7c1a2Y1_P8sGzfe-oYXG0FOs>
Cc: dns-privacy <dns-privacy@ietf.org>
Subject: [dns-privacy] Considering DHCP
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 09:46:23 -0000

HI, Daniel

I think there is no difference when we considering which to do first. If 
the
DHCP could offer a better way, that would be fine. However, there are 
several
problems in the authentication mechanism defined in RFC3118, thus the dhc 
WG
developed another mechanism called secure DHCP ( 
http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/
[http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/] & 
http://datatracker.ietf.org/doc/draft-jiang-dhc-sedhcpv4/
[http://datatracker.ietf.org/doc/draft-jiang-dhc-sedhcpv4/] ) to enhance 
the RFC3118.

I think the key point is whther we could trust a DHCP server just as 
Melinda
mentioned. I'm not sure whether the secure DHCP could solve the "trust" 
problem,
I just provided it here for reference only. If possible, an extension to 
DHCP
may be a good way. Comments are welcome.

Best Regards,
Linhui

2015-04-14 12:36 GMT+08:00 Daniel Kahn Gillmor < dkg@fifthhorseman.net 
[dkg@fifthhorseman.net] > :
[ rearranging for chronological sanity ]

On Tue 2015-04-14 00:02:24 -0400, Zhiwei Yan wrote:
 > [ Paul Wouters wrote: ]
 >> On Tue, 14 Apr 2015, Zhiwei Yan wrote:
 >>> Then why not consider the DHCP?
 >>> DHCP can support client authentication and can be used to configure 
the RS
key on the authenticated client.
 >>> Do you think this will help?
 >>
 >> How do you know the DHCP server is not a rogue attacker?
 >> How does the system determine encrypting to the DHCP/DNS server is
 >> guaranteed to not be eavesdropped on?
 >> It depends on if I trust that network (eg my home) or not (eg 
starbucks)
 >
 > RFC 3118 provides a scheme for this issue:
 > http://www.rfc-base.org/txt/rfc-3118.txt
[http://www.rfc-base.org/txt/rfc-3118.txt]

Haven't we just pushed the problem off a level then?

It seems you've replaced the problem "how do i choose a trust anchor for
my DNS server" with "how do i choose a trust anchor for my DHCP server"?

And the trust anchor framework described in 3118 is pretty weak compared
to the trust anchor frameworks we have available in TLS (problematic
though some of them may be):

Key Utilization:
https://tools.ietf.org/html/rfc3118#section-5.4
[https://tools.ietf.org/html/rfc3118#section-5.4]

Key Management:
https://tools.ietf.org/html/rfc3118#page-16
[https://tools.ietf.org/html/rfc3118#page-16]

In those scenarios where a trust relationship already exists between a
DHCP client and a DHCP server, sure, we should figure out a way to
distribute DNS resolver trust information as well, once we know what
that looks like (e.g. a DHCP extension containing a SHA256-sum of the
DNS server's subjectPublicKeyInfo would be plausible). But again, that
seems like a nice thing to have *after* we've sorted out what the DNS
trust anchor looks like in the manually-configured case.

--dkg

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org [dns-privacy@ietf.org]
https://www.ietf.org/mailman/listinfo/dns-privacy
[https://www.ietf.org/mailman/listinfo/dns-privacy]

v2.23.0 | Report a Bug | By Email