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

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

At Wed, 30 Nov 2016 17:55:00 +0800,
Lishan Li <[e-mail]> wrote:

> > This doesn't sound like reliable for the same reason.  While this can
> > certainly be designed in multiple different ways, I don't see why we
> > might want to allow the server to skip calculating the tag value for
> > its public keys.  It's a one-time operation for each key pair if the
> > server has a volatile storage and can store the value there (which
> > would be quite likely for middle-to-large scale servers).  Even if it
> > needs to calculate the tag value on every startup (and keep it in
> > memory throughout its runtime) it should be quite lightweight.
> >
> [LS]: It is not a one-time operation for each key pair. For different
> clients, the key tag calculation method is different. For the multiple

I don't understand this.  Why is it different for different clients?
Perhaps you somehow assumed I was talking about the use of signature
hash algorithm (which can be different for different clients)?  I
wasn't; I said it didn't sound like reliable, and pointed out that if
we fix the calculation method it's a one time operation and the
overhead wouldn't be a big issue.  Maybe "if we fix the calculation
method" condition wasn't clear enough.

> calculation method, I don' t think it is lightweight.
>
> Assume that the calculation method is needed, which method do
> you suggested?

I have no specific suggestion or preference.  Perhaps just use the
same algorithm as RRSIG key tag?

> > >
> > > [LS]: The Reconfigure message is sent from server to client. So sure,
> > > it should be encrypted in Encrypted-Response message.
> > >
> > > Firstly, I think there is no need to design such a mechanism for it.
> > [...]
> > > key pairs. However, the client always communicates with only one DHCPv6
> > > server.
> >
> > Is this guaranteed by the protocol specification?  If so, could you
> > provide specific text of an RFC (3315? or 3315bis?) that specifies
> > this restriction? [...]
> >
> [LS]: In the case that multiple servers share one common certificate,
> the Encrypted-Query message may be sent to multiple DHCPv6
> servers. But they are informed of the same public key. And the
> client also uses the same one private key for decryption.
> So we can add the statement that: During the DHCPv6 configuration
> process, the client MUST only use one certificate to establish the
> encrypted communicate with the DHCPv6 server.

This didn't answer my question.  Could you first answer the question?
If there's no such restriction in the base protocol, we cannot assume
it and can't assume it in designing sedhcpv6.

--
JINMEI, Tatuya