Re: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhcpv6-21

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?

There's additional information at https://security.stackexchange.com/questions/33434/rsa-maximum-bytes-to-encrypt-comparison-to-aes-in-terms-of-security, 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 [mailto:dhcwg-bounces@ietf.org] On Behalf Of ????
Sent: Thursday, April 20, 2017 1:53 PM
To: Timothy Carlin <tjcarlin@iol.unh.edu>
Cc: dhcwg <dhcwg@ietf.org>; draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
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 <tjcarlin@iol.unh.edu> 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
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

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