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

[Lishan Li <[e-mail]>]

2016-11-02 5:52 GMT+08:00 神明達哉 <[e-mail]>:

> I have a couple of higher-level comments on draft-ietf-dhc-sedhcpv6-17.
>
> 1. I still disagree with the following restriction described in
>  Section 5.4:
>
>    For the privacy consideration, we have to give up the
>    previous server selection feature.
>
>  Especially now that rfc3315bis is going to deprecate the delayed
>  authentication protocol and sedhcpv6 will become the only current
>  candidate to provide security for DHCPv6, I believe it should cover
>  all basic features of DHCPv6 including "the previous server selection
>  feature".  There is at least one way to support this feature
>  (although it's operationally restrictive): share the same
>  private/public key pairs by multiple servers that may respond to the
>  same Solicit.  As far as I can see there's nothing in this
>  specification that prohibits this operation (unlike an earlier
>  version of the spec, we don't include the server ID option in
>  the Encrypted-Query message for a Solicit).  Also the following
>  sentence in Section 10 seems to assume this operation:
>
>    It should be noted that the selected certificate may
>    correspond to multiple DHCPv6 servers.
>
[LS]: Agree to what you said. The current version does not prohibits
this operation. This sentence should be deleted.

>
> 2. Algorithm negotiation still doesn't make much sense to me.  I have
>    many questions and concerns related to this point, but instead of
>    raising each of these, I'd suggest one specific alternative to
>    consider: have the client send a list of supported algorithms in
>    the initial Information-Request, and let the server choose one set
>    of them and keep using the same set.  This way we don't have to
>    worry about an "algorithm not supported" error in the middle of a
>    DHCPv6 session (as a corollary, we don't have to worry about how to
>    return an encrypted reply when the client's preferred encryption
>    algorithm isn't supported by the server).  An obvious downside of
>    this is that it reveals some information of the client (the list of
>    supported/preferred algorithms), but IMO this is acceptable.
>
[LS]: In the current version, the server firstly sends a list of supported
algorithms through the Reply message. Then the client processes it
according to the following method:
"If the checks fails, the Reply message is dropped.  If the
hash algorithm field is zero, then it indicates that the hash
algorithm is fixed according to the corresponding signature
algorithm.  If all the algorithms are supported, then the client
selects one hash algorithm, signature algorithm and encryption
algorithm from the provided algorithms set.  And then the client also
uses the same algorithms in the return messages."
So it is not possible that the the server does not support the
acknowledged algorithms. So we also don't need to worry
about how to return an encrypted Reply when the client's
preferred encryption algorithm isn's supported by the server.
Could you please check whether my understanding correct?

Best Regards,
Lishan