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

[Lishan Li <[e-mail]>]

Please see the question in line.

Best Regards,
Lishan

2016-11-05 1:09 GMT+08:00 神明達哉 <[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
>
[LS]: In this way, we have two public key: public key for E1, and public
key for A1.
Which one will be used for the future encryption process?

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