Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

神明達哉 <jinmei@wide.ad.jp> Wed, 15 February 2017 19:27 UTC

Return-Path: <jinmei.tatuya@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 0BF31129678 for <dhcwg@ietfa.amsl.com>; Wed, 15 Feb 2017 11:27:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 lmv3RLqOlQBB for <dhcwg@ietfa.amsl.com>; Wed, 15 Feb 2017 11:27:09 -0800 (PST)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 3381012998D for <dhcwg@ietf.org>; Wed, 15 Feb 2017 11:27:09 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id s186so162008269qkb.1 for <dhcwg@ietf.org>; Wed, 15 Feb 2017 11:27:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CMHKbQX0mwWqRlfm0IB/BPWvJt9k5PcauXd2cL9kQF4=; b=iGgRtsJfIuPjbWF0b4uxxHPX3xlLot2yaj56dnoMdxCuLwliD0b1s+gbyrC2Xrh0Tm FLvz5lyEppyahqXBIkMmfm2aBlT6peRor1vgNyL+jGvn63TA+ZyDprSg38/zWd/uxwBs 7mKng4V5gqLhi7g1xGkuHSCShX145ydhAmvBREhx2ig6wu2vfWLLwS6PkjUCxGevLVav RuW3UcIaBpD0Nh8W8ZbOK0M9/eH6zeZPJPin9rISqYH1I2V1WuRI09c2SnKfHcRtfWQT WwL79c4ne0fyy2zgczwBGfCRnmg8EH2Xsm6XttAaiD/tqph3NuyznlW7UnBBfBadIb+s JuJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CMHKbQX0mwWqRlfm0IB/BPWvJt9k5PcauXd2cL9kQF4=; b=KjQAWyT3Oxw4zzYVgOyWJDlW4X28oYlsR2LT2Ud3djBHlH/3jbl0qDpCHy1wktaIA+ 7qsVFMcc7fH3rxvrmSS1LUj0YpmLIa4flL3s7WkFMM7VsHXuHDdQdLV9OBgk+Oiyb9U9 VhL1SHYW3l3yj1OvfvdlMhkS7c0EwusBz3TgD6RjYPZjAGhMNdNv36HzyS63K/rG2LFN Wlsf28WZC/0XRTcSfAE/hvZ+eaxRpBaitKEh8S3weTYTCSEHCrKDjJKmQgUMuEpMd+lc Ki/CR0y7Hz5aSbL3t1SCru6Ru08xUVyj5Z+8xKEbUJlePdTLsGAy8KkliWuxg4juhqu4 Blrg==
X-Gm-Message-State: AMke39lnVaGy9Akn0sh19XiJmvPlvyYpikxfb7FVGudRViIL9mRZxtftD+vDbi+9JE48BbGYjpxxM26+9xgNhQ==
X-Received: by 10.55.124.7 with SMTP id x7mr34667140qkc.149.1487186828205; Wed, 15 Feb 2017 11:27:08 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.29 with HTTP; Wed, 15 Feb 2017 11:27:07 -0800 (PST)
In-Reply-To: <CAJ3w4NefG3M0+y53xVKM9fOzLaFDgd9FygbNPC5SFDsGXw55JA@mail.gmail.com>
References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <CAJ3w4NdCk8CBfNagcXT_VW_50+=xK=N7aB5HHqqn3stMt7Gy-Q@mail.gmail.com> <CAJE_bqf_AP9w1Bh_5kSB4YkLaV9XJ1tngufAiOMxVqQLwMruNA@mail.gmail.com> <CAJ3w4NdR-YdNziqK1u_TpExhQLUukpL8uYzEQ4A0MoipOv-Huw@mail.gmail.com> <CAJE_bqeCBjoGj7V1jTxAh_ce4TH3h_VWxFoRim8wU4OHhaLaow@mail.gmail.com> <CAJ3w4NefG3M0+y53xVKM9fOzLaFDgd9FygbNPC5SFDsGXw55JA@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Wed, 15 Feb 2017 11:27:07 -0800
X-Google-Sender-Auth: 3qZO22l7J5kEE4MATRsQRHxO7Ms
Message-ID: <CAJE_bqdJgkbcr8iGomzkHn+doAR+MemGQnyDh8N-0EcemtJM4Q@mail.gmail.com>
To: Lishan Li <lilishan48@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/0UNeR0NMEhd-cLqC4AXO14OwyXk>
Cc: dhcwg <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
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: Wed, 15 Feb 2017 19:27:11 -0000

At Wed, 15 Feb 2017 19:46:27 +0800,
Lishan Li <lilishan48@gmail.com> wrote:

> > Encapsulated in an Encrypted-Response message?  If so, with setting
> > transaction-id to 0 (like Reconfigure itself)?  And is the client
> > supposed to try to decrypt it when transaction-id is 0 even if it
> > doesn't match any outstanding Encrypted-Query it has sent?  And in
> > that case which private key should the client use?  (For the last
> > question, see also the comment on the assumption of the number of
> > client certificate described in Section 6).
> >
> > I think these questions and issues can be addressed relatively easily,
> > but I believe these should be clearly and explicitly described.
> >
> [LS]: How about the following method:
> The transaction-id of the Encrypted-Reponse message MUST be equal with the
> transaction-id of the received Encrypted-Query message and cannot be zero.
> In this way, the client will try to decrypt it.

Assuming the Reconfigure is encapsulated in an Encrypted-Response
message: it won't work since in case of Reconfigure there's no
corresponding message from the client to the server that would be
encapsulated in the Encrypted-Query message in the first place.

> > > >   The description of zero hash algorithm field seems to suggest the
> > > >   signature and hash algorithms are tightly related in practice.  So
> > > >   it may be better to define the algorithm option so that
> > > >   signature/hash algorithms are listed as pairs.
> > > >
> > > [LS]: Yes. In some cases, the signature and hash algorithm are tightly
> > > related and cannot be separate. Sorry that I don't understand that
> > > "it may be better to define the algorithm option so that signature/hash
> > > algorithms are listed as pairs", Could you please explain it more
> > clearly?
> >
> > For example, instead of listing SA-id List and HA-id List separately,
> > we might have unified SA-id List:
[...]
> > and each pair of (SA-id[i], HA-id[i]) will be considered to specify a
> > specific signature method.
> >
> [LS]: So, for every SA-id, there is a corresponding HA-id or multiple
> HA-id(s).
> SA-id and HA-id are set to a pair. Right?

In this example, yes.  But I'm not necessarily insisting on this
particular example itself.  My concern with the currently described
way is how to address cases like:

- the client includes SA0, SA1, HA0, HA1 in the algorithm option.  It
  supports the combinations of (SA0, HA0) and (SA1, HA1), but not (SA0,
  HA1) or (SA1, HA0)
- the server returns a certificate with the combination of (SA0, HA1)
  or (SA1, HA0)

So the higher level question is whether and how to address this
concern.  The above example approach could be one solution to it, but
it can make the algorithm option unnecessarily larger.

> > > > - Section 6
> > > >
> > > >    [...] In this document, it is assumed
> > > >    that the client uses only one certificate for the encrypted DHCPv6
> > > >    configuration.  So, the corresponding private key is used for
> > > >    decryption.
> > > >
> > > >   I'm not sure if this is okay.  And, in fact, Section 11 talks about
> > > >   a case where multiple key pairs (so multiple certificates) are used:
> >
> [LS]: We have discussed this issues before.
> In most cases, a client will not uses multiple certificate(s) for the
> encrypted DHCPv6 configuration process in the same time. Please see the
> following reasons:
> After the client authentication, the client will use the public key in the
> certificate option for encryption. The server only knows one client's
> public key for encryption. And the client will also only uses one private
> key for decryption. So there is no cases that the client will use one key
> pair for the encryption of some DHCPv6 messages and use another key pair
> for the encryption of another DHCPv6 messages.

This is fine, but I was wondering what if the client has multiple
DHCPv6 sessions with different DHCPv6 servers using different key
pairs.  It's probably very rare in practice, so I can live with saying
such an operation is outside the scope of this spec.  But I'd like to
see wg consensus on this, and if we reach it I'd like it to be
explicitly documented.

--
JINMEI, Tatuya