Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

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

At Sun, 20 Nov 2016 01:11:18 +0800,
Lishan Li <[e-mail]> wrote:

> > My understanding of where we are is that we now agree that as of
> > sedhcpv6-17 the server can't efficiently identify the private key to
> > decrypt a message in an Encrypted-Query message.
> >
> > I can think of two possible next steps from here:
> > 1. leave the inefficiency: let the server try all possible private
> >    keys until it can decrypt the message or conclude no key works.
>
> 2. introduce some kind of concept of "key ID" (or "key tag", in which
> >    case 100% uniqueness isn't required) and have the client include it
> >    in Encrypted-Query messages.
> >
> [LS]: I don't know why in this case, 100% uniqueness isn't required.
> Key id is used as the identifier of the private key, can the two private
> key (two clients) uses the same key id?

Because it's basically for making the key identification more
efficient.  It's similar to the key tag field of DNS RRSIG RDATA
(see RFC4034 Section 3.1).

> > I personally prefer option #2, but in that case I don't like to
> > overload the existing transaction-id field for this purpose.
> >
> [LS]: The standard DHCPv6 message format contains the
> transaction-id. If the transaction-id is not contained, then the
> message is not DHCPv6 message. Transaction-id field's size
> is very small.
> In the before presentation, we have showed that Encrypted-Query
> and Encrypted-Response messages are DHCPv6 messages.
> And no one proposed any problem. And I also think that
> there is no problem. If you insist on your opinion, please
> states the caused problem and modify the draft. I don't
> have any comment on this.

I didn't propose removing transaction-id.  I just pointed out that
your proposal (if I understood it) made it something actually
different from transaction-id.  I don't know whether we need to have a
discussion why "naming something that is not a transaction ID a
transaction-id is a problem", but if we can simply go to a discussion
on what we should actually do, my suggestion is:

- Introduce a new DHCPv6 option named "encryption key tag option".
  Its value is calculated from public key data (it's essentially a
  fingerprint of a specific public key).
- Encryption Query messages MUST include the encryption key tag
  option.  The option data MUST be calculated for the public key that
  the client uses to encrypt the encapsulated DHCPv6 message.

--
JINMEI, Tatuya