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

[神明達哉 <[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.

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.

--
JINMEI, Tatuya