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

神明達哉 <jinmei@wide.ad.jp> Mon, 24 April 2017 22:54 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 8362112706D; Mon, 24 Apr 2017 15:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
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: 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 SNVq1lZ-Vwvx; Mon, 24 Apr 2017 15:54:41 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 F09E7126FDC; Mon, 24 Apr 2017 15:54:40 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id m36so126826609qtb.0; Mon, 24 Apr 2017 15:54:40 -0700 (PDT)
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=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; 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=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 10.200.51.132 with SMTP id c4mr28242310qtb.13.1493074479961; Mon, 24 Apr 2017 15:54:39 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.208 with HTTP; Mon, 24 Apr 2017 15:54:39 -0700 (PDT)
In-Reply-To: <fd5cbf00959446228ba18a796e7d5eff@XCH-ALN-003.cisco.com>
References: <CAJE_bqdJKbe7mSLNnk24-_ZACd_U6EGbjaFQ8v6xYy=nuPiUbw@mail.gmail.com> <fd5cbf00959446228ba18a796e7d5eff@XCH-ALN-003.cisco.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Mon, 24 Apr 2017 15:54:39 -0700
X-Google-Sender-Auth: EUJJaS-J-RwDzgM9g7EKYiKVTNU
Message-ID: <CAJE_bqc_eJCQpB=fxGcxAiLbPVZsDSwh958GvvAyiKZ3CSeaCg@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: Timothy Carlin <tjcarlin@iol.unh.edu>, dhcwg <dhcwg@ietf.org>, draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/_BsaCWbFOLrFkDw_0njRDc1lYQI>
Subject: Re: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Apr 2017 22:54:43 -0000

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

> Perhaps the RSA limitation can be resolved as described in https://tls.mbed.org/kb/cryptography/rsa-encryption-maximum-data-size.
>
> 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