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

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

On Fri, Nov 4, 2016 at 8:04 AM <[e-mail]> wrote:

>> [LS]: I don't think that the client/server need to contain all the
>> supported
>> algorithms. In default, all the servers and clients support the mandatory
>> encryption, signature, hash algorithms. So the client/server may just
>> need to contain the preferred algorithms and some of mandatory
>> algorithms.
>
> I was probably not clear enough by "all the supported algorithms", but
> this is actually what I meant: all the preferred algorithms, and I
> thought it was wasteful.

To be a bit more specific, consider the following case:

Assume the server supports the following algorithms
  For Encryption: EM, E1
  For Signature: AM, A1, A2
  For Hash: HM, H1, H2
  (where EM, AM, HM are the mandatory algorithms)

Also assume algorithms for Ex and Ay are all completely different and
we need different public keys (thus different certificates) for all of
them.  And also assume we can use any combinations of Az and Hw to
construct the Signature option.  And suppose the server most prefers
E1, A2, H2 because these are the strongest, but it cannot assume a
particular client supports this combination.

Now, for the currently described protocol to work, the server will
need to include the following in response to the initial
Information-Request:

- Certificate for the public key for EM
- Certificate for the public key for E1
- Certificate for the public key for AM
- Certificate for the public key for A1
- Certificate for the public key for A2
- Signature using AM and HM
- Signature using AM and H1
- Signature using AM and H2
- Signature using A1 and HM
- Signature using A1 and H1
- Signature using A1 and H2
- Signature using A2 and HM
- Signature using A2 and H1
- Signature using A2 and H2

This is the (unavoidable) waste I'm envisioning in the current
protocol (or am I misunderstanding it?).

On the other hand, if we let the client tell the server supported
algorithms in Information-Request, the client will only have to show a
list of supported algorithm IDs.  For example, if the client supports
EM, E1, AM, A1, and HM, the client will only have to send an ID of
these 4 algorithms (10 octets in total).  These are all supported by
the server, so the server will return a Reply containing:

- Certificate for the public key for E1
- Certificate for the public key for A1
- Signature using A1 and HM

which (we assume) is the most preferred combination for the server,
and it's guaranteed the client understands it.

--
JINMEI, Tatuya