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

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

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

=> I don't buy this argument as the certicate alone is useless (i.e.,
you need the validation path/chain, CRLs, etc).

> It is also introduce some DDOS risks.

=> it is the use of certificates which introduces some DDoS risks...

>  May we reach agreement on the below statement:
>  
>  1. From the above discussion, the certificate option is already defined for 
>  client-to-server.

=> but nothing more than the certificate option so IMHO this part of
the current proposal is strickly NOT applicable.

>  So, keeping certificate as an alternative will not introduce any harm.

=> it is just useless complexity so it introduces 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 obta
>  ining certificate chain from SEND.

=> this argument is based on the wrong assumption the whole certificate
is needed to recognize it. It is fully wrong: an X.509 public key
certificate is only a signed public key with attributes.
Note you can argue you can get more than one certificate sharing the
same public (and private) key. IMHO  this is more than bad practice
so there is no need to support it (i.e., looking for the first
matching certificate is enough).

To summary the choice is between dropping the certificate stuff
or to fix it with for instance a profile, etc. It could take years
to get seDHCPv6 so please keep it simple...

Regards

[e-mail]