Re: [dhcwg] Open Issues for Secure DHCPv6

Lishan Li <lilishan48@gmail.com> Sat, 02 July 2016 09:58 UTC

Return-Path: <lilishan48@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00B412D0A1 for <dhcwg@ietfa.amsl.com>; Sat, 2 Jul 2016 02:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rvvGo4QvTHz3 for <dhcwg@ietfa.amsl.com>; Sat, 2 Jul 2016 02:58:18 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 07FFA12B009 for <dhcwg@ietf.org>; Sat, 2 Jul 2016 02:58:18 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id j2so179146105qkf.3 for <dhcwg@ietf.org>; Sat, 02 Jul 2016 02:58:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ochakxkVqusdhbg3dyqzM1+yd17zrAbivfXqxJtXN0U=; b=eRrRO8OzaEp7k6IHC4ZGhJtChrkojTQy16QiLdubKOAZncT/1cyZLnzHStw8XSEw4Y 0DiGjqjHqwzWf899TMq+pD8sefATg52DtrRVwEmLs1ScoDFTbgyPGagtKpFGE/OG1P4I ROKojFOEHNb9e54eqxvC5mCN5TYCqfTHD4eWy17PMDeHiLZ8I7yo8BbSwdnhVuHk+I29 Z4ZInJlUGFoYMwZ1d3/Oe8XpLPaKQi7gunzEI1Ioey7s8zBF2/qCNnHL9wmYEaOzJH4/ U0E7aLjjWHlZ3hB/O8qukkTpxqht0V5KD+5e7AML215AdQee+u9mIin1GyePeD3n3WJY Nq3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ochakxkVqusdhbg3dyqzM1+yd17zrAbivfXqxJtXN0U=; b=fhg2dJcaBNqUKiCNm9GkzR5T0X4e8IYyWKZRBMw6J28hEF+7sCwgGycTBr9cpZn38n VBH8VTKhO4PDFmW5ho/v4pjjN6toOFjkuR6CuDK7gYaIH6w/01FZXa8MMkmkyMxuHxle XlOHEV4lFRw6KAw8vp7Dron/S902kkeo4WQDLcfl1xeeU74YK3WV4zL8lUdFoMBF41t7 SIOWLfKTnpGXXbudCnZpJ/ox6S90x+GI1pXZgjA22W2MLuuM6JelU2Gj+GufQ8IPnOPs CX4cd88SjPcCS5/CPTdLAD8dUQoVXT17EDXiQ0QxuFr6HNOzffUQM6gLrOQjqfJsPnC0 hhqw==
X-Gm-Message-State: ALyK8tLZa5o0PS57G3agF8B/cfqOdaKtdpA9COZK4Qx9FTjeYgsazgMZ+LLhimQZ5NaW9E1WdqI0g1bXc4pO4Q==
X-Received: by 10.233.220.132 with SMTP id q126mr3508812qkf.53.1467453497213; Sat, 02 Jul 2016 02:58:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.44.65 with HTTP; Sat, 2 Jul 2016 02:58:16 -0700 (PDT)
In-Reply-To: <CAJE_bqdQUy3jeTOT2Sb2A9VgRJXYP30mBw6yB4S7iP0jMqO1kQ@mail.gmail.com>
References: <CAJ3w4NeoF7DC91ST=814wq61cTXd8SYUDT1VvJ73Uy_Vhoqk3A@mail.gmail.com> <CAJE_bqdQUy3jeTOT2Sb2A9VgRJXYP30mBw6yB4S7iP0jMqO1kQ@mail.gmail.com>
From: Lishan Li <lilishan48@gmail.com>
Date: Sat, 2 Jul 2016 17:58:16 +0800
Message-ID: <CAJ3w4NcsHCeqJf+rpRvJ7sZKGgNHqKQ36aUbeK7sc2=SEvC3zw@mail.gmail.com>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary=94eb2c043ade6d06610536a42464
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/9mmyWb2NTOD2PCiEtfUnAbeAWI8>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Open Issues for Secure DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 02 Jul 2016 09:58:21 -0000

Dear Jinmei,

Please see inline.

Best Regards,
Lishan

2016-06-16 1:04 GMT+08:00 神明達哉 <jinmei@wide.ad.jp>jp>:

> At Wed, 15 Jun 2016 22:57:11 +0800,
> Lishan Li <lilishan48@gmail.com> wrote:
>
> > After the discussion with authors and Stephen Farrell, we have the
> > following problems not sure and want to get further comments from WG.
> >
> > 1. For the applicability part, after the discussion with Jinmei, we want
> to
> > made the following changes:
> > (1). Add some opportunistic security related description in applicability
> > part;
> > (2). Support the following two modes of operations: 1.
> > Authentication+Encryption with cert/public key validation; 2. (if #1
> isn't
> > possible) Encryption-only without cert/public key validation.
> >    The current version only includes "Authentication+Encryption" mode. We
> > should add the "Encryption-only" mode.
>
> I think some more background explanation is needed here...this is
> simply based on my *understanding* (not opinion) of what we agreed at
> the Yokohama IETF meeting.  I thought our consensus was to support the
> above two modes, while the current sedhcpv6 draft only talks about
> Authentication+Encryption.  I guess there is some possible confusion
> on what "TOFU is out of scope for now" means
> (see agenda #4 of
> https://www.ietf.org/proceedings/94/minutes/minutes-94-dhc).
>
> My understanding is that it was only about authentication and the
> consensus was to add support for "encryption only".  Am I
> understanding it correctly?
>
> BTW, if we make this change, I don't think we can simply update the
> applicability section - it will lead to quite substantial overhaul for
> the entire document.
>
> [LS]: Sure. Besides applicability section, we should update the whole
document
to describe the encryption-only mode. In addition, we also need to some
explanation
on why Tofu is out of scope currently. Right?



> > 3. The Reply message with an error status code, is not encrypted. So the
> > Reply message may contain the client identifier option, then the client's
> > privacy information may be disclosed.
> > So the solution is that: The Reply message can be encrypted to avoid
> > privacy information disclosure.
>
> This is not so trivial.  At least it will be tricky in case of
> 'AlgorithmNotSupported' - how can the server encrypt it when it
> doesn't support the encryption algorithm?

[LS]: If the server does not support the algorithm that the client used.
It can encrypt the Reply message with the mandatory algorithm.
Right?