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

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Apr 2017 10:53:22 -0700

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 22 Apr 2017 16:59:32 +0000

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:[email-masked]] On Behalf Of ????
Sent: Thursday, April 20, 2017 1:53 PM
To: Timothy Carlin <[email-masked]>
Cc: dhcwg <[email-masked]>; draft-ietf-dhc-sedhcpv6 authors <[email-masked]>
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 <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Mon, 24 Apr 2017 15:54:39 -0700

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

> 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