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

[Lishan Li <[e-mail]>]

Dear Jinmei，

If the Information-request message indicates the algorithms, then we need
to make the following update:
1. The Information-request message contains the new define algorithm
option, which contains the EA-id List, HA-id List, SA-id List;
2. The Certificate option contains the EA-id field, not EA-id List. And
signature option contains the SA-id field and HA-id field, not SA-id List
and HA-id List.

Could you please check whether my understanding correct?

Best Regards,
Lishan

2016-11-07 15:00 GMT+08:00 Lishan Li <[e-mail]>:

> Hi, Jinmei,
>
> Thanks a lot for your detailed explanation. Agree to what you said. Will
> modify it according to your comments.
>
> 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
>>
>> which (we assume) is the most preferred combination for the server,
>> and it's guaranteed the client understands it.
>>
>> --
>> JINMEI, Tatuya
>>
>
>