Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt

[Sheng Jiang <[e-mail]>]

>>  >The second point is about (X.509 public key) certificates. They are useless
>>  >without the trust anchor, the whole chain, CRLs, etc. And if we want
>>  >to use self-signed certificates they bring nothing compared to raw
>>  >public keys. And I don't talk about profiles (even SeND had to be
>>  >completed by RFC 6494). So I really suggest to drop the certificate
>>  >option and to use the key option to identify the public key.
>>
>>  Actually, certificate would be very useful for server to authorize the clien
>>  t. It is much less useful on a client, who have not been allowed to connect
>>  on line. In such case, certificate can be used with LoF, which is equal usag
>>  e as identify the public key.
>
>=> for the first point something like the URI and hash from IKEv2 is
>IMHO far more usable than to put the certificate inside the message.

We did discuss URI for certificate in DHC WG before. It is the WG consensus not to use URI, because it introduces additional overhead and time delay to server to download the certificate. It is also introduce some DDOS risks.

>And I disagree about the second statement: there is no reason to
>give up about the server authorization. 
>It is a hard problem but
>not an untrackable one (as SeND proved). For the last a public key
>option is simpler and more efficient so it is not an argument for
>keeping the certificate option.
>
>>  >The last point is compatibility with SeND (RFC 3971). Today in red and
>>  >black (:-) environments it is possible to secure the Neighbor Discovery
>>  >but not DHCP. I propose to fix this using the secure DHCPv6 for
>>  >the protection of DHCP and the SeND section 6 Authorization Delegation
>>  >Discovery for the "certificate part".
>>
>>  Could you be more clear how this may work? I am not sure I fully
>understand
>>  your proposal. So far, SeDHCPv6 has no compatibility issues with SeND,
>becau
>>  se they are two solutions independent from each other. We don't want to
>intr
>>  oduce any dependency between them, which would make the deployment
>much more
>>  complicated.
>
>=> I don't want to introduce dependency but to make them to be able to
>work not only together but in complement, exactly as DHCPv6 and ND are
>(even it took a very long time to finalize all details).
>The missing part in SeDHCPv6 is the authorization, i.e., all the higher
>order thing about certificates. This is already handled in SeND, perhaps
>not in the best way, so the idea is to say for SeDHCPv6 + SeND we don't
>need to reinvent the wheel.
>This could leave two use cases for SeDHCPv6: LoF or statically
>pre-configured SeDHCPv6 using raw public keys, and SeDHCPv6 + SeND
>for strongly secured environments. Perhaps not the whole thing we want
>but enough to "sell" a first version.

May we reach agreement on the below statement:

1. From the above discussion, the certificate option is already defined for client-to-server. Using the certification option on the server-to-client can archive the same function as public key, in LoF mode. So, keeping certificate as an alternative will not introduce any harm.

2. The client may get support from another mechanism to be able to validate the server certificate (transmitted by the certificate option), such as obtaining certificate chain from SEND.

Regards,

Sheng

>Regards
>
>[e-mail]