Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

神明達哉 <jinmei@wide.ad.jp> Tue, 29 November 2016 16:23 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 DB186129BF7 for <dhcwg@ietfa.amsl.com>; Tue, 29 Nov 2016 08:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 B8bjrK45EC82 for <dhcwg@ietfa.amsl.com>; Tue, 29 Nov 2016 08:23:55 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 F412B129BFD for <dhcwg@ietf.org>; Tue, 29 Nov 2016 08:23:54 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id q130so179714636qke.1 for <dhcwg@ietf.org>; Tue, 29 Nov 2016 08:23:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=X86vUocgTjSvIBIUe2/1Ad/K9jEV0OlHh17gh+I4Ygc=; b=Zcqr6gIhJ0i0wkk5ub5v6nftjU9bMj3J0O8rOex2jpFaYGXz9+rVgeiXL+nAKhUTXC +HZC/Rhfh9WRJSbRZH0SGUi0nK/g0MxOm9fauk5G+EF5Y7K87OAj3o3elzKZuj0AomBX d8cQJdvZkEcpyP1tysaEJbYaElovJUCVlqxAKrrEuRuyPKr6mmyIZ/WfrGg3K4Q07yjI AbBNNFx4iFZZ5Yi3Lel6R8Ig5zIH0idsY4DkohhNRYNxFj4l1qiAs4vp6UOGIbxJTcsJ AHyZXELi0TlGD3SM+jfgl3WpEtYCQPylOtLEMyKN2ChyDFuftqRwPmDnA2R0rjwWlez4 D8Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=X86vUocgTjSvIBIUe2/1Ad/K9jEV0OlHh17gh+I4Ygc=; b=EL2Fp/BbVLsW7xrM273pdgLa/hiVj5Xg4dcI+MeeGU5wPY+G4CLDWzr7y0XP6cqupQ Xgqfe7EkFNU5lL7sWhQmmwZApJDgmRlNHn2MYG8u8Dagno8JLaBFP0ILCaX4it3rNgER Z/0kNwFGnWdvqh686wzTdk5NXu9o6LlYVYIit+YbPOz6YTT+gMuRR6vznQAKZQIUKbL3 Iph9RhRYvCvSRBDxYFlUoM3O6NflwTh20NYvysAczYz0pUT0aCwtIhMsjJhJ6IRUU081 xYqBmHE5Vc/1U/oNDra6rfwEpXisHnNzRxH/D+PLif38AbN/OnY5olMDC19yrrAvGAi+ mqXg==
X-Gm-Message-State: AKaTC03VAjvJCKuZxoRyvyOTUlxDZm931J8d5hJfrPIpUKy7GJ4m4/EzWNu8tXzLz6/kw8AIrOrPYP6BP2DO/g==
X-Received: by 10.55.20.164 with SMTP id 36mr23930306qku.86.1480436634049; Tue, 29 Nov 2016 08:23:54 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.53.155 with HTTP; Tue, 29 Nov 2016 08:23:53 -0800 (PST)
In-Reply-To: <CAJ3w4NcnAe3Enhs6KVgBkpa+BivLGRw9SGJ1RmAq7q=HM8Ph6Q@mail.gmail.com>
References: <CAJE_bqebwr2WUUgaNgiYS4_8L77Gxj4Os+oPRG407B6ELMEhCQ@mail.gmail.com> <CAJ3w4Ndi5Gq63n5kZnanRhLM8nWE2wsWGh0kJJLJnq=VoXLuCg@mail.gmail.com> <CAJE_bqegh1DfWjfK2BxeC_fWa0cEk-KJNP0AT-TQuEa39w_wVQ@mail.gmail.com> <CAJ3w4NdM99nv4C19Xj=aosNme+_Ymyys=xQ3UWUfeZReZC4ckA@mail.gmail.com> <CAJE_bqdhGZnK16MooiyujDgthDNnR74EiwW0OevrN6uq4b4ANw@mail.gmail.com> <CAJE_bqfKUZe2yaW1sAq7rrib0M7wz28HHtPLqCHK=vXcN6amgg@mail.gmail.com> <CAJ3w4Nd3s+ZojjiotLkKwys6truhUgK6F-90UYjcpB9iw=fKKQ@mail.gmail.com> <m2r36nuqvn.wl%jinmei.tatuya@gmail.com> <CAJ3w4NeuNYTrX4p5rtZ6UceD5ydQ-B-vY6aqQzxWnXsrDOEFEA@mail.gmail.com> <CAJE_bqdh-bgk7BHZJnaFFBr3PDj4ZnSSGeGNdQ70F7dv91iQrA@mail.gmail.com> <CAJ3w4NfU9PrC9a+MGnJ=Es1yir_asHB3p1=9GfxZZ0iSe+At+Q@mail.gmail.com> <CAJE_bqfRBYkrniWQ+vtPULTURnvyV792QNGvr8JhhZpGQ0MSdA@mail.gmail.com> <CAJ3w4NerRzHYsRqcUAkAjHX23PYVF4Jv0wKcd33vXRRg+-0EAQ@mail.gmail.com> <CAJ3w4NekPk0TuAZW_jmTDYQHd8JP3GsrA0qrKYrnyqSSk3qwxw@mail.gmail.com> <CAJE_bqc8hkrc3dYefTPWi-mUCtZD+oYsrobCK1KjmVGRnNfMCw@mail.gmail.com> <CAJ3w4NejrFAT3RK7i0W46HkQNJjhPxbhzQiL=3fcrceidTzHNQ@mail.gmail.com> <CAJE_bqcCwZWPHuZ0UR8_jyCUsaTrYKzLD8zUKwChYaCL06yT9A@mail.gmail.com> <CAJ3w4NfS8PKOMHcP5s_Nsp5K5eWJfXWRF-vNEau_ekqTRwE=wA@mail.gmail.com> <CAJE_bqfqSXFR9R5wf1USg-zs+nvdohQFq99kQL2DiapXvUdEqA@mail.gmail.com> <CAJ3w4Ncj40JwrW6UB+TVFvymByU5Y9iFv5QroWhwUzkLrS2DTg@mail.gmail.com> <CAJE_bqd38grUh9q57a-H29GsMx5Dpv9VE0iBMO7v_-y97zZZUg@mail.gmail.com> <CAJ3w4Ne63cnqoeTZk=PDmAN9+i6jwzyxbK+up45wB9h+xUDSfw@mail.gmail.com> <CAJE_bqceK7YLpMqhgjqrFQh7641a+ZRcnO0F6p6BiM8EMKmA7w@mail.gmail.com> <CAJ3w4Nf65b1zo-smMguZBc_-RbFh2y8kk7Fnu__TKCQEVbs48w@mail.gmail.com> <CAJE_bqeVciLxS_q=deRKLBr12ZGXxx2wdFiztJxJjfS7aAV2Ag@mail.gmail.com> <CAJ3w4NcvyeuRWJatGGH7U4g413GQvr9LHtDiX13zSOz7kBGEhw@mail.gmail.com> <CAJE_bqfFOhe26huAP8_BFKjnTXbG4F0vUfMYs5Xy=3RQigS7FA@mail.gmail.com> <CAJ3w4Ne81LVsaznu_yck7fG7iJyGm=WY4=i2AF8gx39Tf59eMA@mail.gmail.com> <CAJE_bqceRD2+vkfwR+Egr=CgyAT4wd1Wmxp1S=f3WRFGs9j4sg@mail.gmail.com> <CAJ3w4NcnAe3Enhs6KVgBkpa+BivLGRw9SGJ1RmAq7q=HM8Ph6Q@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Tue, 29 Nov 2016 08:23:53 -0800
X-Google-Sender-Auth: ZeXMw6mcZGg_zSBne3o6AFsKzlE
Message-ID: <CAJE_bqcTpK0j_yfza3KPavEgdcpk2z+ZivZt8Hs1m2NrE7_scA@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/l5YJv2bTAAaFCgIm1ZG6Qhg2vk4>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17
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: Tue, 29 Nov 2016 16:23:58 -0000

At Tue, 29 Nov 2016 23:19:55 +0800,
Lishan Li <lilishan48@gmail.com> wrote:

> > We need to describe it as part of the protocol as it's necessary for
> > interoperability.  It's similar to the fact that the calculation of
> > the DNS RRSIG key tag is part of the protocol standard.
> >
> [LS]: OK. So how about using the hash algorithm for the encryption
> key tag calculation?

Do you mean the hash algorithm used for the signature option?  If so,
it doesn't sound like a reliable choice since it can be different for
different clients.

> Maybe the server don't need to know the calculation method. For the
> first Encrypted-Query message with the new encryption key tag, the
> server tries all the possible private keys and record the relationship
> between the key tag and the corresponding public/private key pair.
> And the server does not need to calculate the key tag locally.

This doesn't sound like reliable for the same reason.  While this can
certainly be designed in multiple different ways, I don't see why we
might want to allow the server to skip calculating the tag value for
its public keys.  It's a one-time operation for each key pair if the
server has a volatile storage and can store the value there (which
would be quite likely for middle-to-large scale servers).  Even if it
needs to calculate the tag value on every startup (and keep it in
memory throughout its runtime) it should be quite lightweight.

> > In this case we can normally use the transaction ID (unlike the case
> > where the server needs to identify the key pair to decrypt the
> > received data)...except for Reconfigure.  So, in the end we probably
> > need to include the key tag option in the Encryption-Response
> > message.  Hmm, this leads to another question: which encryption
> > message should we use, Encryption-Query or Encryption-Response, to
> > encrypt a Reconfigure message?
> >
>
> [LS]: The Reconfigure message is sent from server to client. So sure,
> it should be encrypted in Encrypted-Response message.
>
> Firstly, I think there is no need to design such a mechanism for it.
[...]
> key pairs. However, the client always communicates with only one DHCPv6
> server.

Is this guaranteed by the protocol specification?  If so, could you
provide specific text of an RFC (3315? or 3315bis?) that specifies
this restriction?  I agree that it's the most common way of DHCP(v6)
operation, but unless it's explicitly stated in the protocol
specification I think it's dangerous to design other protocols based
on such an implicit assumption.  I'm okay with the assumption itself,
but if it's an explicit restriction of the base protocol I'd suggest
explaining the assumption explicitly.

> For the whole DHCPv6 configuration process, only one public
> key is informed of the server and the corresponding public key is used
> for decryption.
>
> Assume it is need to design a mechanism for this. There are three method:
> 1. Transaction id as the identifier: now work for Reconfigure message;

I'm not sure if I understand this, but transaction-ID doesn't work in
the case of Reconfigure.

> 2. Encrypted-Response message contains key tag.

Yes, this can be one option.  Perhaps we might say:

- An Encrypted-Response message that encrypts a Reconfigure message
  SHOULD include Encryption Key Tag Option
- Encrypted-Response message MAY include Encryption Key Tag Option
  for other cases
- The client can use the key tag option (if included) or transaction
  ID (if non-0) to identify the private key to decrypt the data in a
  received Encrypted-Response message.  In practice, it's more likely
  that the client has only one possible key pair so the choice should
  be obvious.

> 3. Server Identifier as the identifier.

This can also work, but in that case we should update the spec so
Encrypted-Response messages can include the server identifier option.
It also relies on the assumption that there is only one DHCPv6 session
between the client with one particular server or if there are multiple
parallel DHCPv6 sessions the same key pair is used for all sessions.
As noted above, I'd be cautious to rely on implicit assumptions, so if
we choose this option I'd like to make the assumption explicit.

--
JINMEI, Tatuya