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

"Bernie Volz (volz)" <> Sat, 22 April 2017 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DF6F127077; Sat, 22 Apr 2017 09:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZsQGRsf6QDmv; Sat, 22 Apr 2017 09:59:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 245301294AB; Sat, 22 Apr 2017 09:59:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3912; q=dns/txt; s=iport; t=1492880374; x=1494089974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PKMh1oKuOepMSH2Ovr7CXw86HTsVqIRB/BO/z+X03q0=; b=GmPeJgZ63xmZJfqxdtEb6qTWnBtPrm7QZXXczYcl55Qy7TWNQ/7yjcga Uw1nh8yvB3mN1WpROp5g/8PnzhXE+kKQRD6kJoEcLzdWHo9+X9ZOmWanX DTRuG/1zNeiFXgUCDoML9Trg9G8G5MlTJXNW3H4s5MIROmw+MjVgtQpsP E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,234,1488844800"; d="scan'208";a="416179076"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2017 16:59:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v3MGxXUd022561 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 22 Apr 2017 16:59:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 22 Apr 2017 11:59:32 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Sat, 22 Apr 2017 11:59:32 -0500
From: "Bernie Volz (volz)" <>
To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= <>, Timothy Carlin <>
CC: dhcwg <>, draft-ietf-dhc-sedhcpv6 authors <>
Thread-Topic: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th)
Thread-Index: AQHSuf8ILJ2o6tUo4E2uk2ZsrOk7tqHRm15Q
Date: Sat, 22 Apr 2017 16:59:32 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Sat, 22 Apr 2017 16:59:36 -0000

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?

There's additional information at, which basically implies that calculating K once and reusing it would be sufficient.

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

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of ????
Sent: Thursday, April 20, 2017 1:53 PM
To: Timothy Carlin <>
Cc: dhcwg <>rg>; draft-ietf-dhc-sedhcpv6 authors <>
Subject: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th)

At Wed, 5 Apr 2017 13:13:38 -0400,
Timothy Carlin <> wrote:

> I'm also wondering about using RSA for encryption, as the data size 
> (and thus message size) is limited to the key size that the client or 
> server provides.  This could cause problems with large DHCP messages.  
> Could a symmetric key algorithm (e.g. AES) be used?  The keys for this 
> would have to be negotiated during the initial Information-request/Reply.

I agree the data size limitation of RSA can be critical.  At least data for the very initial Encrypted-Query message is quite unlikely to be encrypted at once, since the data contains a certificate option (which contains the client's public key).  Assuming a 2048-bit key, we can only encrypt 256 - (overhead for padding etc) octets of data at once.  I'm afraid this is too limited even for subsequent messages that don't contain the certificate option.  One straightforward workaround is to divide the data and encrypt each chunk separately, but this may not be acceptable due to the cost, especially for the server.  (Even if we adopt this approach I guess the current draft text is too unclear about it and should be revised to describe specifically how to do it).

I suspect using symmetric session keys can't be an (easy) option, either.  At least I don't think we can do this negotiation in the initial Information-Request/Reply exchange, since to do so the client would have to include its certificate in the Information-Request message but we intentionally avoid that due to a privacy concern.

In any case, I'm afraid this issue will require some substantial changes to the specification.  Right now I don't have a clear idea about what's the best.

JINMEI, Tatuya

dhcwg mailing list