Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

Ralph Droms <rdroms.ietf@gmail.com> Sat, 17 May 2014 22:21 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B551A021A for <dhcwg@ietfa.amsl.com>; Sat, 17 May 2014 15:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 0HR9v-kcF4hR for <dhcwg@ietfa.amsl.com>; Sat, 17 May 2014 15:21:38 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474FA1A0119 for <dhcwg@ietf.org>; Sat, 17 May 2014 15:21:38 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id fa1so4066625pad.25 for <dhcwg@ietf.org>; Sat, 17 May 2014 15:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=foyvmKTDOz29SpYrrGF/ETIb/qBi8/lsMJZdWH+ecRk=; b=KzKxvlhdkll3QGeZIy9SwSrmNZdvfU11HXth/E1HHHRvCUehbCz4fBPBeUorWDFjV/ 37Sz/qkD48k4kJbuYcxznPie/Dpu3zA9WvjE2dS3ddWt+81Sv6xp1DQ4/ouY7drX9CD/ xzBvSH4zmFtx3r6r1A+Bg4if0GqfQwelCUpvVvhZM+0ZrUzUZWfb7mjl5CVDRiS6r6UX uS18N/QanxOx4fsj0do1+9e2MxpPVlPfACTsVR5yfSv5ZP3wIcc7IhngmZt/VUfkdGnY uceF9QOp45ACMcDEGV8q5VA+qdOP7zPggUsFqgKPaW+a+7jZHuof9FwmJIgYv4rG91cB 9M7Q==
X-Received: by 10.66.142.233 with SMTP id rz9mr31692863pab.71.1400365297930; Sat, 17 May 2014 15:21:37 -0700 (PDT)
Received: from sjc-vpn6-1565.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPSA id au4sm21738798pbc.10.2014.05.17.15.21.35 for <dhcwg@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 May 2014 15:21:36 -0700 (PDT)
From: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <1C435EB5-6982-4A07-A89D-769A954821A2@gmail.com>
Date: Sat, 17 May 2014 15:21:41 -0700
To: dhcwg <dhcwg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/zcLT-cd0gftd64MTZK5oMixQ5vA
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 May 2014 22:21:40 -0000

After reading the document, I don't fully understand where this
mechanism would be useful and where it wouldn't.  The meta-question
here is "what security problem does this mechanism solve?".

draft-ietf-dhc-sedhcpv6-02 defines a PKI/cert mechanism and talks a
little about leap-of-faith mechanisms/TOFU.  But the document doesn't
talk about various attack scenarios and which of those scenarios are
mitigated by the mechanism described in the draft.

TOFU prevents subsequent attacks by other servers once the client has
decided to TOFU some server, right?  How does that mechanism work:

1. in a home network?
2. in a Starbucks?
3. in a university/school?
4. in an enterprise?
5. when attaching to an ISP?

Put simply, do I have it right that the "leap of faith" prevents
future attacks spoofed as coming from that server?  The client has no
knowledge about whether the server might mount an attack itself.

Trusting a cert requires some way to evaluate that cert's
trustworthiness. Seems applicable in some scenarios (maybe #4 above)
but not in others ... unless we implement some huge infrastructure for
handing out "approved DHCP certs".

Specific questions:

Can a server send a secure DHCPv6 message in response to an insecure
message from a client?

What is the definition of "secure model" in section 4.3?  I assume you
mean the client should "start by sending secure DHCPv6 messages".

In section 4.3, suppose a DHCPv6 legacy DHCPv6 server decides to
discard a secure DHCPv6 message (which may not be compliant with RFC
3315).  I suggest the document recommend that a client fall back to
non-secure DHCPv6 messages if it receives no response to secure DHCPv6
messages.

Section 6.2 mentions the requirement for a "local trust public key
list".  In my opinion, this requirement is a very important
characteristic of the security mechanism described in this document,
and should be explained much earlier in the document.