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

[Lishan Li <[e-mail]>]

2016-11-30 23:34 GMT+08:00 神明達哉 <[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]: I have no idea to complete it. Please contribute the text about it.

>
> > > >
> > > > [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.
>
[LS]: I just think that it is a default fact. Could you please give an
example that the client communicates with two DHCPv6 servers
for the address configuration in the same time?

Best Regards,
Lishan