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

Lishan Li <lilishan48@gmail.com> Wed, 30 November 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 C672B129ED7 for <dhcwg@ietfa.amsl.com>; Wed, 30 Nov 2016 01:58:47 -0800 (PST)
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 jYTiJGL0DQAq for <dhcwg@ietfa.amsl.com>; Wed, 30 Nov 2016 01:58:45 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 CD29A129EDE for <dhcwg@ietf.org>; Wed, 30 Nov 2016 01:55:01 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id p16so182179902qta.0 for <dhcwg@ietf.org>; Wed, 30 Nov 2016 01:55:01 -0800 (PST)
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=k1M9QaEjrC1mxloADLvUWYWaV4m5ewR/LclymhuRcDE=; b=Muwut0fZwXtvHNoBl7Sdvtxd1uOqo7whCeZGLaxqb2k11JK4zR2X57gUYD3UzfW2nk 2/PFCufnC7g+Fewv2taI1EkV7LgwLDoK/qNhypiBj5cdRpTn4L9wiXe7oiosL1oobY+B q7SUZ1OBoQ2DKKztoeGvylpxMD/EbnHzpO9Z+Xv2SbavjRU2U1cU7Vvexx/9XgOXeKGK 5Sc7AY+CdiTsQ3+Fb/dzpsQF6/tcvAS+tgq89obw23lY3yz6qrcUbC6+nRbjR2w+u8g1 UKc9nyLIGJ4TliJZs2W02SwbeuquMwzFUiIMePFF4KHKgreMssCZW+5nhC1ZqT6F1Syx s/Xw==
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=k1M9QaEjrC1mxloADLvUWYWaV4m5ewR/LclymhuRcDE=; b=OwXirkIDuUuRx1gUdsDbBUCmNeQJdwx0KrBmEUAqutQKYcLVJIYQlDHCYxPwT2Tm7/ ZeYu7hZM3VZ9dimcfXwPxnPPyuTuvLSzQgGeH1iD+T9DGO4T7k1s+81WOWuFytMXwPs/ diB6qD7DDuIoND1w11AZurMW+QZhSvE4vpNec+5ygXKELQyhDt1+rOr44WbiA7T6aHyI TBOYU7t5RGVspjN/WD64TmmEhxmIV6rdnlEv6ZhqgYengOyHXFLeqM7gnQVd63ZyWaZD 9dvDMombf0/PZA9MNg0KSM3MHlDSiHUMzA2oLxt+CR3BRA8oOQmcYiHRS8VSHKrF+7pM 4qzQ==
X-Gm-Message-State: AKaTC02ngBWJIgZ++4Qn9JVPVvseQlpiN5kIFC6O1ClOzFrEyHAIlJdGXyuNBqfwCH0Q0AO/LxveA/40OcDbYA==
X-Received: by 10.200.34.108 with SMTP id p41mr31476865qtp.269.1480499700970; Wed, 30 Nov 2016 01:55:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.211 with HTTP; Wed, 30 Nov 2016 01:55:00 -0800 (PST)
In-Reply-To: <CAJE_bqcTpK0j_yfza3KPavEgdcpk2z+ZivZt8Hs1m2NrE7_scA@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> <CAJE_bqcTpK0j_yfza3KPavEgdcpk2z+ZivZt8Hs1m2NrE7_scA@mail.gmail.com>
From: Lishan Li <lilishan48@gmail.com>
Date: Wed, 30 Nov 2016 17:55:00 +0800
Message-ID: <CAJ3w4NfEqpZu+fYO_1A06bVT2Qzqc1qyTi_NkKrBjWGCJGwJVA@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary="001a11422baac43b92054281b20e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/nQsmE5hTbZYFxj2etX2EIJsXzNQ>
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: Wed, 30 Nov 2016 09:58:48 -0000

2016-11-30 0:23 GMT+08:00 神明達哉 <jinmei@wide.ad.jp>:

> 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.
>
[LS]: It is not a one-time operation for each key pair. For different
clients, the key tag calculation method is different. For the multiple
calculation method, I don' t think it is lightweight.

Assume that the calculation method is needed, which method do
you suggested?

>
> > > 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.
>
[LS]: In the case that multiple servers share one common certificate,
the Encrypted-Query message may be sent to multiple DHCPv6
servers. But they are informed of the same public key. And the
client also uses the same one private key for decryption.
So we can add the statement that: During the DHCPv6 configuration
process, the client MUST only use one certificate to establish the
encrypted communicate with the DHCPv6 server.

>
> > 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.
>