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

[Lishan Li <[e-mail]>]

2016-11-23 1:53 GMT+08:00 神明達哉 <[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.
>
[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.
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.

Best Regards,
Lishan