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

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

>  The way I understand this is:
>  
>  - In order to make communication more secure, time settings in the two
>  ends need to be "close enough"

=> yes

>  - To make sure the time settings are synchronised, you want to introduce
>  a synchronisation step at the beginning of the communication, then time
>  settings will be close enough

=> no, I only propose for nodes without a good real time clock
and which believe they could be out of synchro to recover first.

>  - Now communication can proceed using time as part of the transaction

=> it was already the case: the trade-off is between secure/small
window or reliable/large window, and I only propose a way to choose
the first (i.e., more secure) at a minimal cost with the hardware we
have today...

>  If I want to attack the end that needs to be synced, here is my plan:
>  - Start the synchronisation procedure, but set time to fit the replay
>  attack I have in mind. This could be weeks away from today's time
>  (depending on the synchronising procedure)

=> this is possible only when you have a rogue but trusted server.
In this case a replay is not the problem.

>  - After this step, the remote end has a completely different time than
>  what it should be.

=> DHCP is not peer-to-peer but client-server.

>  I possibly missed something here

=> DHCP is not a general protocol (and BTW your concern is not in fact
about synchronization but timestamps, and seDHCPv6 is based first
on signature, not on timestamps, so unsigned messages are simply
considered as unsecure and should be dropped if the policy requires
secure messages).

Regards

[e-mail]