Re: [dhcwg] Additional feedback on secure DHCPv6 draft

神明達哉 <jinmei@wide.ad.jp> Mon, 27 July 2015 20:29 UTC

Return-Path: <jinmei.tatuya@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 1DD051A8896 for <dhcwg@ietfa.amsl.com>; Mon, 27 Jul 2015 13:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 13i_4sryAvUT for <dhcwg@ietfa.amsl.com>; Mon, 27 Jul 2015 13:29:56 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 A76D21B33AA for <dhcwg@ietf.org>; Mon, 27 Jul 2015 13:29:56 -0700 (PDT)
Received: by iggf3 with SMTP id f3so93443166igg.1 for <dhcwg@ietf.org>; Mon, 27 Jul 2015 13:29:56 -0700 (PDT)
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=5ttAfNf81LeVwhFm300bSfzsWgHvMzXfMIUYEb2prj0=; b=aJXLJiBS/NL4eq+RZ/xaDHBTmKqbStOXL2rr+Otw0i0/2425On03ZtnCITJQmn0vIA YXzojehEI5dP2oMP+3vLJNKGptNIzOZ2Nmayp9z6BDHCTW6wgx65kMq9335o8ADUWSlt XYLq/LLR+pKUAjv4Y5/aqJfphiGX32eqUOPEZESspZ1x9OptWPtOdMsr6H+Hw065IPTI f3jPp+LhB1xHHGzFlDr8ABsIm0Z1JgUJlcXF8NH7y4SQkbmFT0nzifChfY2G07VtGvJ6 sOdDwoWOVbx7GwLs/lboO/2xmBr3W0avhzabrt2tWOeVH66rxidHRoiARHD7dC5q+0Bh j70A==
MIME-Version: 1.0
X-Received: by 10.50.79.169 with SMTP id k9mr18459463igx.44.1438028846058; Mon, 27 Jul 2015 13:27:26 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.19.139 with HTTP; Mon, 27 Jul 2015 13:27:25 -0700 (PDT)
In-Reply-To: <201507201403.t6KE3XpN042259@givry.fdupont.fr>
References: <55ACE8AA.300@innovationslab.net> <201507201403.t6KE3XpN042259@givry.fdupont.fr>
Date: Tue, 28 Jul 2015 05:27:25 +0900
X-Google-Sender-Auth: OiZkQ8YxYOstUjANsfZJum7GYHo
Message-ID: <CAJE_bqd_=EXU6FiozR_AWEapSxzgZBei5enKh6snNwE+Sgcy3w@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Francis Dupont <Francis.Dupont@fdupont.fr>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/F3YRRqEKG2SKPdE2e6oRh90Ng-4>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Additional feedback on secure DHCPv6 draft
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 27 Jul 2015 20:29:58 -0000

At Mon, 20 Jul 2015 16:03:33 +0200,
Francis Dupont <Francis.Dupont@fdupont.fr> wrote:

> >  A big question that probably should be answered in the introduction or
> >  under security considerations is "what security vulnerabilities are we
> >  trying to mitigate?".
[...]
> >  Given all that, what are the threats?
>
> => for me the main 2 examples is the guy which tries to get your address
> (i.e., inpersonate your application server) and the bad guy which
> releases your address (i.e., basic denial of service).

These can be prevented with the existing RFC3315 authentication
mechanism.  So we'd need to explain why we need to introduce a new
mechanism to prevent them.  To that end, and in my understanding of
previous discussions, all we can say is this:

> But in fact the goal is to raise the DHCPv6 security from its current
> level (i.e., nearly no usable security at all) to a point where it is
> not too ridiculous compared to SEND (RFC 3971).

but unless we show how we can practically integrate PKI (or some other
way for public key distribution/sharing) with secure DHCPv6, or at
least show how TOFU could effectively prevent some class of threats
that are not so marginal, it would still look equally "ridiculous" and
wouldn't be convincing.  This has been my own concern (but admittedly
I failed to resolve myself), and, according to the external reviews
and Brian's initial feedback, this concern seems to be shared by
others.

I'm not sure how we can move forward from this point.  I'm pessimistic
about revising the document so it can show the integration of PKI or
more persuading scenarios of TOFU based on the history of this
document.  So the only alternative I can think of is to make it super
clear that "this is still mostly as 'ridiculous' as the RFC3315
authentication mechanism as we don't know how to integrate PKI, but
we'll just define this mechanism as public key based authentication is
generally considered the modern practice" (with more sophisticated
rhetoric:-).

I didn't attend the dhc meeting in Prague (or remotely) so I don't
know if there was any discussion on the possible next step for this
document.  Is there any agreed way to move forward?

--
JINMEI, Tatuya