Re: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th)

神明達哉 <> Mon, 24 April 2017 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8362112706D; Mon, 24 Apr 2017 15:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SNVq1lZ-Vwvx; Mon, 24 Apr 2017 15:54:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F09E7126FDC; Mon, 24 Apr 2017 15:54:40 -0700 (PDT)
Received: by with SMTP id m36so126826609qtb.0; Mon, 24 Apr 2017 15:54:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kQ9xbMxuAzvehp8C1VcSswoEQiylJ6+JrBboI7SRhE4=; b=ek7VwNYZpt60qcu3YTAtV+UHzp5Um+TOgEKMfIuRop7dpevcmlXtIT7LWWP4rbGMon yuczlivsih7cvXt8opapcYDPHkJi60lhJmhu7GEUxtUUJb0GEtJyOsX4IqaTICkUnpn0 fy6r/vlumXbphZQnAnH3l3Jt6ItdQb0qgZI/dnpizPqnTijbeNuT2SGjxd+sg7DRbqL4 l7H2+8QrPy/qPhApBal6Dbkc8zl6X64MeD3alGuM24O1+3Rmz86OTmN9nydHmGCmDxmW +cXf7FZX155qPhyohRnJvP+ZIDIvnKHxzb+kVRNQGM3o1t0/U9jdimzZpFZ42aJmABdZ YeZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kQ9xbMxuAzvehp8C1VcSswoEQiylJ6+JrBboI7SRhE4=; b=c22uMWuO7y0r2AIDcfYBnmNGNoDnm0jPBihnpBJcOsg+Dh7NkpW8/zsBiq6ns4gQpN +P20coRfTtE8aRpJoxeBWIX7ZaqI7OqJOnoZ91eBw8Fr5Qec8JsdLSYr87WmvhjgeKJ9 t1LNZx08w910mwqunjsmJpG2HDevWLuTO9t3ea9bVpA/D7R9JUvKlAc9Ow2fd2Y3rgGa F3Tq9sTulWXE/NuzBZEy+IVZUhFGIrSphuybfq+d1jMoFgsuLUkWeRgARL4dB/t0B1IU ALR2a0wWCxNkM3EJzIFZ3YxboH1zGHKjD7xV0ipj5dtzbReZDQWN6QP3DAD/fYkAaSbO fsww==
X-Gm-Message-State: AN3rC/5puObG9RorTIU9BpZXOO70jMQE026mlxj93k1FvCrjWdIRuQsS Xw42V9tYzRjh+JMoBZzzGG+GJ0mpl0fk9ME=
X-Received: by with SMTP id c4mr28242310qtb.13.1493074479961; Mon, 24 Apr 2017 15:54:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 24 Apr 2017 15:54:39 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Mon, 24 Apr 2017 15:54:39 -0700
X-Google-Sender-Auth: EUJJaS-J-RwDzgM9g7EKYiKVTNU
Message-ID: <>
To: "Bernie Volz (volz)" <>
Cc: Timothy Carlin <>, dhcwg <>, draft-ietf-dhc-sedhcpv6 authors <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Subject: Re: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Apr 2017 22:54:43 -0000

At Sat, 22 Apr 2017 16:59:32 +0000,
"Bernie Volz (volz)" <> wrote:

> Perhaps the RSA limitation can be resolved as described in
> Generate a 256-bit random keystring K
> Encrypt your data with AES-CBC with K
> Encrypt K with RSA
> Send both to the other side
> Not sure if generating the 256-bit random keystring  would be done
> for each message exchange, or perhaps just once (such as initially
> for the Reply to the Information-Request) and both the client and
> server use the same K for subsequent messages. This  might be
> sufficient?

This is basically one form of "using a symmetric session key", so we'd
use the same K for all subsequent messages.  But this can't be in the
Reply to the initial Information-Request, since at that point the
server may not know the client's public key.  So I'd expect the client
to generate K and include it (encrypted with RSA) and actual data
(encrypted using K) in the initial encrypted message to the server.

> But there's also the problem of the server determining which K to
> use to decrypt the message since it may have LOTS of K's - one for
> each 'active' client. Perhaps that means the server needs to provide
> some kind of index for which K and the client includes this (in
> plaintext).

Right, and

> The downside is that it lets someone determine when a
> particular client is doing a DHCPv6 exchange, but that probably can
> be derived from some of the network metadata anyway (i.e., the
> client's source address). Perhaps the server just uses that metadata
> (i.e., client's source address or Relay-Forw peer-address) for the
> server to determine the K. This does mean the client must use the
> same link-local address for the "life" of the DHCP transactions
> using a particular K.

I wouldn't too much worry about the identity disclosure due to that.
As you said, unless the client keeps changing the link-local address
to send DHCPv6 messages, the same level of identify is already
disclosed.  But if we really worry about it, we could also include
the encrypted K in all messages to the server.

In any case, I believe this problem can be solvable, but will require
a quite substantial update to the current spec.

JINMEI, Tatuya