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

[Lishan Li <[e-mail]>]

2016-11-19 3:51 GMT+08:00 神明達哉 <[e-mail]>:

> At Fri, 18 Nov 2016 00:56:35 +0800,
> Lishan Li <[e-mail]> wrote:
>
> > [LS]: Thanks a lot for your explanation.
> > Then, for the next step, the transaction-id of Encrypted-Query and
> > Encrypted-Response message works as identifier for the public key
> > of encryption and private key for decryption.
> > When receiving the first Encrypted-Query message, the server has
> > to try all the private keys that it might use.
> > Could you please check whether my understanding correct?
>
> Hmm...I'm afraid I don't understand your understanding:-)
>
> 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?

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

Best Regards,
Lishan