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

[神明達哉 <[e-mail]>]

At Wed, 5 Apr 2017 13:13:38 -0400,
Timothy Carlin <[e-mail]> 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