[dhcwg] Review of draft-ietf-dhc-sedhcpv6-01

[Qi Sun <[e-mail]>]

Hi all,

I volunteered to review the document. Here are my comments (sorry if some of them have been discussed). But most are editorial. 

1. Technical
1) About the Signature Option
a) Different description of Signature Option:
Sec 5.3: "It protects the entire DHCPv6 header and options, except for the Authentication Option.” 
Sec 6.1: "It protects the message header and the message payload and all DHCPv6 options except for the Signature option itself and the Authentication Option.”

b) As is described above, Signature option does not protect itself including the timestamp which will be used to judge the message's validity. It means attackers can change the timestamp without destroying the signature. So attackers changes the timestamp of message, then the recipient will inspect the signature which is "correct" despite the change of the timestamp. This might cause a replay attack.

2) Inequality on the bottom of Page 12
"TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz"

What if RDnew < RDlast, maybe caused by a bad clock? In this case, the inequality holds (so that the message is accepted) but there might be something wrong. For the security reason, it would be better to drop the message, IMHO.

2. Editorial
1) Section titles:
Sec 3: Security Overview of DHCPv6
Sec 4: Secure DHCPv6 Overview
They are kind of close at the first glance.
Suggestion:
s/Sec 4: Secure DHCPv6 Overview/Sec 4: Secure DHCPv6 Mechanism Overview/

2) Add a section of Terminology
There are some terms that are not well-known to the readers. It would be clearer if a section of Terminology could define them before using.
For example:
CA; leap of faith mode; TSlast; RDlast; TSnew; RDnew; drift; etc.

3) Sec 3, 2nd paragraph (and followed paras)
Unnecessary indentation

4) Sec 4, 3rd para
  In this document, we introduce a public key option, a certificate
  option and a signature options with a corresponding verification
  mechanism.
s/a signature options/a signature option/

5) Sec 4.1, bullet 1
  A second option is defined to carry the certificate.
s/A second option/Another option/
Note: “A second option” reads like the two options are kind of linked to each other. But from the description, the two options should not appear at the same time.

6) Sec 5.1
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     OPTION_Public_Key         |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                Public Key (variable length)                   .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s/OPTION_Public_Key/OPTION_PK_PARAMETER/

7) Sec 5.2
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    OPTION_Certificate         |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                Public Key (variable length)                   .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s/OPTION_Certificate/OPTION_CERT_PARAMETER/

8) Sec 6.2, the last para
   A Relay-forward or Relay-reply message with any Public Key,
   Certificate or the Signature option is invilad.  The message SHOULD
   be discarded silently.
s/invilad/invalid/
Use MUST instead of SHOULD?

9) Sec 6.3, 1st para
   Actually, be definition in
   this document, relay agents MUST NOT add any secure DHCPv6 options.
10) Sec 6.4, bullet 2
   o  The time stamp in the last received and accepted DHCPv6 message. 
      This is called TSlast. 
s/time stamp/timestamp/

11) Sec 7, 3rd para
   The Secure DHCPv6 mechanism is based on the pre-condition that the
   recipient knows the public key of senders or the sender’s certificate
   can be verified through a trust CA.
s/through a trust CA/through a trusted CA/


12) Sec 7, Page 14
   However, the two communciating nodes can be synchronized is out of
   scope of this work.
s/the two/how the two/
s/communciating nodes/communicating nodes/

Best Regards,
Qi