Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

[神明達哉 <[e-mail]>]

On Wed, Mar 8, 2017 at 5:36 AM, Tomek Mrugalski
<[e-mail]> wrote:

> Authors believe this draft to be ready for working group last call.
>
> Please send your substantial comments to the mailing list and express
> your opinion whether this draft is ready for publication.

See below.

> 2. One of the authors suggested that this protocol is quite complex and
> having a feedback from an implementation (or ideally two interoperating)
> would be very important and would likely result in some changes to the
> draft. It's probably too late for Chicago, but we can organize a
> sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE
> and Kea, as those two are open source and have an old version of the
> draft partially implemented. Do you think such a hackathon would be
> useful? Are you willing to participate?

I think a hackathon for this is useful.  I'm not sure if I attend the
Prague meeting at all, but if I do I'm willing to participate in the
hackathon.

The rest is my response to the last call and comments on
ietf-dhc-sedhcpv6-21.

Personally I won't support publishing it until I see at least one
implementation of this spec (I know it's only me and I know it's not a
formal prerequisite for passing a WGLC).  I also think the issue about
Confirm (for which I've sent a separate message) should be resolved
first.

Another high level concern is that we've had very few reviews on this
document so far.  I have some feeling that the wg as a whole actually
is not interested in this topic.  If that's the reality we may even
have to consider abandoning it.

That said, I'm providing my own review comments on the draft.  I
believe most of them are straightforward to address, but there's at
least one non-trivial proposal: regarding the use of transaction-id
value of 0 for Reconfigure.

- Section 1

   This document provides a brief summary of the security
   vulnerabilities of the DHCPv6 protocol and then [...]

  On a fresh read I've realized it doesn't really talk about general
  "security vulnerabilities of the DHCPv6 protocol".  I suggest
  revising it as follows:

   This document provides a brief summary of the issues of current
   security mechanisms for the DHCPv6 protocol and then [...]

- Section 6

   [...] In some scenario
   where non-authenticated encryption can be accepted, such as coffee
   shop, then authentication is optional and can be skipped.

  I don't think non-authenticated encryption is *acceptable* in the
  coffee shop scenario.  We use it in that case since it's just better
  than nothing.  I suggest:

   [...] In some scenarios, such as for coffee shops, full
   authentication is hard to deploy but opportunistic security
   (i.e., encryption without authentication) may be still helpful.
   In such cases authentication is optional and can be skipped.

- Section 6

   [...]  If the transaction-id is 0, the client
   also try to decrypt it.  Then, the client extracts the Encrypted-
   message option and decrypts it using its private key to obtain the
   original DHCPv6 message.  In this document, it is assumed that the
   client will not have multiple DHCPv6 sessions with different DHCPv6
   servers using different key pairs and only one key pair is used for
   the encrypted DHCPv6 configuration process.  [...]

  This is not very readable.  I know it talks about key identification
  and the rationale for the case of tid=0.  But I suspect it's
  difficult to understand for those without background discussion.  I
  also wonder whether we really need to impose the assumption of "only
  one key pair".  This is only necessary for a rare case of Redirect;
  for other normal cases the client should be able to identify the key
  from the transaction id.  I'd rather suggest removing the assumption
  and having the client try all possible keys in case of tid=0 (but in
  practice the number of possible keys to be tried should be very
  small, and quite likely to be one).  For these reasons I suggest
  revising the whole paragraph as follows:

   For the received Encrypted-Response message, the client MUST drop the
   Encrypted-Response message if other DHCPv6 option except Encrypted-
   message option is contained.  The client then identifies the public
   key to decrypt the message encapsulated in the Encrypted-message
   option.  If the transaction-id of the Encrypted-Response message is
   not 0, there should be a corresponding Encryption-Query message for
   a particular DHCPv6 session.  In this case the client uses the
   private key of the key pair used in that session.  If the
   transaction-id of the Encrypted-Response message is 0, this means
   it encapsulates a Reconfigure message (see Section 7).  In this
   case the client MUST try the private keys of all DHCPv6 sessions in
   use at that point.  Note that the number of such sessions should be
   very small, most likely just one, in practice.  After the
   decryption, it handles the message as per [RFC3315].  If the
   decrypted DHCPv6 message contains the Increasing-number option, the
   DHCPv6 client checks it according to the rule defined in Section
   9.1.

- Section 6 (and as part of general design): related to the previous
  point, I think it's better to prohibit the transaction ID of 0 for
  Encryption-query messages (the client must re-generate the ID when
  its implementation generates 0).  Otherwise it's possible for the
  client to see a 0 transaction ID in Encryption-response messages for
  normal cases other than Reconfigure.

- Section 7

   [...] The
   server selects one hash, signature, encryption algorithm from the
   acknowledged algorithms sets for the future communication.  And then,
   the server replies with a Reply message to the client.  The Reply
   message MUST contain the requested Certificate option, which MUST be
   constructed as explained in Section 10.1.2, and Server Identifier
   option.

  This could read as if there's exactly one (and only one) Certificate
  option in the Reply, but there can be actually two, one for
  signature and one for encryption, right?  Then above text should be
  revised to make it clearer.

- Section 7

   Once the client has been authenticated, the DHCPv6 server sends the
   Encrypted-response message to the DHCPv6 client.  If the DHCPv6
   message is Reconfigure message, then the server set the transaction-
   id of the Encrypted-Response message to 0.

  This is awkward.  The first sentence seems to assume a normal
  exchange (client sends some message and the server responds to it),
  but that's not the case for Reconfigure.  I suggest revising it as
  follows:

   Once the client has been authenticated, the DHCPv6 server sends the
   Encrypted-response message to the DHCPv6 client.  The server may
   also generate a Reconfigure message encapsulated in an
   Encrypted-response message to a client with which a secure DHCPv6
   session has been established.  In the latter case the server sets
   the transaction-id of the Encrypted-Response message to 0.

- Section 9.1

  I still don't understand how exactly this works.  From a quick read
  of his comments I guess Bernie already made the same question in
  more detail, so I just point out that it's not clear to me either.

- Section 9.2

  I don't think we need to paste the reference C implementation; a
  reference to appendix B of RFC4034 should be enough.  Besides, the
  code comment is incorrect:

           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
           unsigned int keysize  /* the RDLENGTH */

- Section 10.1.1

               [...] This design
               is adopted in order to provide encryption algorithm agility.

  I suggest removing this sentence (for EA-id, SA-id, and HA-id).  We
  already know it's for algorithm agility at this point of the
  document; I don't see the need for repeating it again and again.

- Section 10.1.1: in my understanding EA-id in the algorithm option
  must not be 0.  Is that correct?  If so, I think it's better to be
  described explicitly.  Same for SA-id.  On the other hand, I guess
  HA-id can be 0, in which case signature algorithm also identifies
  the hash algorithm.  This should also be explicitly documented.

- Section 10.1.2: in my understanding it's possible that EA-id and
  SA-id are both non-0.  In fact, it's probably the typical case for
  the current mandatory algorithms (both are RSA-based).  I think it
  should be noted explicitly.

- Section 10.1.3

   The Certificate option carries the certificate of the client/server,
   which is contained in the Reply message.

  I believe it's also included in other messages from the client.

- Section 10.1.3

   o  SA-id: Signature Algorithm id.  The signature algorithm is used
      for computing the signature result.  This design is adopted in
      order to provide signature algorithm agility. [...]

   o  HA-id: Hash Algorithm id.  The hash algorithm is used for
      computing the signature result.  This design is adopted in order
      to provide hash algorithm agility.  [...]

  "This design is adopted in order to provide signature algorithm
  agility" should better be removed (see above).

- Section 10.1.3: I don't think the current description is sufficient
  to understand how to calculate the signature.  IIRC older versions
  of sedhcpv6 (pre-encryption versions) explain it in more detail.  We
  should provide the same level of details.

- Section 10.2

   transaction-id  The transaction ID for this message exchange.

  I propose transaction-id value of 0 must be prohibited for
  Encryption-Query message (see above).  If we agree, this description
  should note that.

- Section 10.2

   options         The Encrypted-Query message MUST contain the
                   Encrypted-message option, Encryption-Key-Tag option
                   and Server Identifier option if the message in the
                   Encrypted-message option has a Server Identifier
                   option. [...]

  This is a bit ambiguous to me.  Suggestion:

   options         The Encrypted-Query message MUST contain the
                   Encrypted-message option and Encryption-Key-Tag
                   option.  If the message in the Encrypted-message
                   option has a Server Identifier option, the
                   Encrypted-Query message MUST also contain a Server
                   Identifier option. [...]

- Section 11

   If the client tries more than one cert for client authentication, the
   server can easily get a client that implements this to enumerate its
   entire cert list and probably learn a lot about a client that way.
   For this security item, It is RECOMMENDED that client certificates
   could be tied to specific server certificates by configuration.

  The second sentence is hard to understand and awkward anyway.  It's
  not clear what "this security item" means, and the combination of
  RECOMMENDED and "could be" sounds awkward.

- Section 12

   Hash Algorithm for Secure DHCPv6.  [...]

             Name        |  Value  |  RFCs
      -------------------+---------+--------------
            SHA-256      |   0x01  | this document
            SHA-512      |   0x02  | this document

  I believe we should also add a value 0x00.

   Signature Algorithm for Secure DHCPv6.  [...]

             Name        |  Value  |  RFCs
      -------------------+---------+--------------
         Non-SigAlg      |   0x00  | this document

  I'd add an internal reference to this document (also, the term
  "Non-SigAlg" should be explicitly defined).  I'd also note that,
  though maybe not here, this value can't be used in the algorithm
  option.

  Same for Encryption algorithm and Non-EncryAlg.

--
JINMEI, Tatuya