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

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

>  >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.
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.

Regards

[e-mail]