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

[Lishan Li <[e-mail]>]

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

> At Wed, 23 Nov 2016 16:28:54 +0800,
> Lishan Li <[e-mail]> wrote:
>
> > > - 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.
> > >
> > [LS]: I agreed. I have two questions:
> > 1. How does the client calculate the key tag? Maybe the hash
> > function can be used for the calculation.
>
> Anything that would generate reasonably different values for different
> keys (but it doesn't have to be guaranteed) is fine.  A simple
> "checksum" like the RRSIG key tag would probably suffice; using a
> commonly known modern hash is also fine.
>
[LS]: So it is mostly a implementation problem and don't need to specify
it. Because for the algorithm agility, we defines the algorithm negotiation
mechanism between the client and server. So I the key tag generation
algorithm may also need negotiation mechanism. And then, the generation
algorithm should also be defined in our document.
Looking forward to your guidance.

> 2. For the first received Encrypted-Query message, how does the
> > server identifies the corresponding private key through the acknowledged
> > key tag?
> > one way is that: The server tries all the possible private key
> > and record the relation of key tag and the corresponding private key.
> > Another method is that: The server calculates the key tags of all the
> > private key and then finds the corresponding private key.
> > Looking forward to your further guidance.
>
> IMO this can be left to implementations.  But I expect most server
> implementations will calculate the tag value when it generates a key
> pair and maintain it with the key pair.  Note that if the server
> implementator and administrator don't care about the efficiency it
> could even calculate the tag value for its all public keys and compare
> it to the value specified in the "encryption key tag option".  Or it
> could even skip using the key tag and try all possible keys.  It's
> inefficient but will still work.
>
[LS]: Thanks a lot for your explanation. So we don't need to specify
this implementation problem in our document.

Best Regards,
Lishan