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

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

At Thu, 3 Nov 2016 16:36:46 +0800,
Lishan Li <[e-mail]> wrote:

> > 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:
[...]
> 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.

One issue of this approach is that there's no way to recover from the
situation where the client doesn't support any of the server-supported
algorithms.  Also, the server will have to include certificates of all
the supported algorithms and signatures for all combinations of
supported hash and signature algorithms as it doesn't know which of
these works for the client.  This along with requiring the server
to always include mandatory algorithms will make this approach
workable, but it seemed to me to be unnecessarily wasteful and
complicated.  Hence my suggestion.

Besides, the current draft is not clear that the server needs to
include all certificates and all combinations of signatures.  It's
also awkward to mention the AlgorithmNotSupported status code if "it
is not possible that the the server does not support the acknowledged
algorithms".  So, whether or not my suggestion is adopted, the current
version of draft has a lot of readability and technical issues (and so
I think it's way far from being ready for a last call).  These are
actually what I'd raise once I get to the point to discuss the content
of the draft, but I wanted to address the higher level matters first.

--
JINMEI, Tatuya