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

["Bernie Volz (volz)" <[e-mail]>]

Hi:

I have reviewed the draft and support it moving forward. However, I do have some issues I think need to be addressed but they are mostly fairly small.

I do want to thank the authors for addressing my earlier issues. I think the document is in MUCH better shape now!!

So here goes ...

Section 6:
The sentence: "The encryption text SHOULD be formatted as explain in [RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording in the RFC. Could "encryption text" be clarified? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I am not following what this sentence means and what I should do (if I were implementing this).

Note: This same text is also in Section 7 (last paragraph) and needs similar attention.

Section 7:

   option.  Then, the server checks the Server Identifier option.  The
   DHCPv6 server drops the message that is not for it, thus not paying
   cost to decrypt messages.  If it is the target server, according to

I think here you also want the server to proceed if there is NO Server Identifier option? It should only ignore it if there is a Server Identifier option and it does not match this server's identifier?

Section 8

   those present in the innermost encapsulated messages from the client
   or server.

I think messages should just be message as there is only one message?

Section 9.1:

Might be better to split out requirements for a client and server into separate paragraphs (1st paragraph)? Might also be best to be clear that you address:
1. What a client must remember about its own increasing number (i.e., what it sends to the server).
2. What a client must remember about the server's increasing number (i.e., what it receives from server).
3. What a server must remember about a client's increasing number (i.e., what it receives from client).
4. What a server must remember about its own increasing number (i.e., what it sends to clients). I assume a server does NOT need to keep a unique increasing number set for each client it communicates with - a server can use one set for all clients?
Please also be clear about how each of these 4 (2 numbers on client, 2 on server) are handled. The text presently is not very clear -- for example a client can't forget what it sent if the server remembers it.

Later, be clear that this is modulo 2^64 math:

   The Increasing-number option in the received message passes the
   increasing number check if NUM.REC is more than NUM.STO.  And then,
   the value of NUM.STO is changed into the value of NUM.REC.

   The increasing number check fails if NUM.REC is equal with or less
   than NUM.STO.

"More" here is in the modulo arithmetic "more" -- perhaps use "more (modulo 2^64)" and "or less (modulo 2^64)"?

Section 9.2:

I wonder if you should revise the code to make it more appropriate for this document? RDATA/RDLENGTH aren't really appropriate? 

Section 10

There are now only three (not six) status codes.

Section 10.2

   msg-type        Identifier of the message type.  It can be either
                   Encrypted-Query (TBA7) or DHCPv6-Response (TBA8).

Change DHCPv6-Response to Encrypted-Response.


Section 11

   There are some mandatory algorithm for encryption algorithm in this

Change (first) algorithm to algorithms? Or, change "are some" to "is a"


   Likewise, since the Encryption-Key-Tag Option isn't protected, an
   attacker that can intercept the message can forge the value without
   detection.

Isn't this generally useless? As the message is encrypted, the validation will fail?


Some even more MINOR comments (these would perhaps improve readability but would likely be addressed by the RFC editor):

Section 6:

Perhaps replace "contained" and "contain" with "included" and "include" in the sentences later in that same paragraph (with the "The encryption text...").


   For the received Encrypted-Response message, the client MUST drop the
   Encrypted-Response message if other DHCPv6 option except Encrypted-
   message option is contained.

How about:

   For the received Encrypted-Response message, the client MUST drop the
   Encrypted-Response message if it contains any option other than a single
   Encrypted-message option.

Note: There are some other odd uses of contain (when at least I think the text should use include). But it may not be worth trying to change these (the usage is tricky - you can google for "english contain vs include" if you like). We will leave it to the RFC editor to perhaps clean these up if appropriate.


      The client MAY use the AuthenticationFail as a hint and switch
      to other DHCPv6 server if it has another one.  

Change to "to another DHCP server if it has one"?

Section 7:

   Upon the receipt of Encrypted-Query message, the server MUST drop the
   message if the other DHCPv6 option is contained except Server

Here "the other" should change to "another".

Note: There are several other places where contained/contain would (at least in my mind) be more "standard" if the text used included/include. Same goes for use of "other" (-> another).

Last paragraph of section 7, "then the server set the". Set should be sets.

Section 10.1.1

For EA-len, might be good to add "(must be a multiple of 2)"
For SHA-len, might be good to add "(must be a multiple of 4)"

Also, I think you should change all "2-octets value" to "2-octet value".

Section 11

   For this security item, It is RECOMMENDED that client certificates
   could be tied to specific server certificates by configuration.

Lower case "It"?


General

There are uses of "cert" and "certs" and "certificate(s)". Are these one in the same? Shouldn't we just use "certificate" throughout? Or perhaps you should add "cert(s)" to terminology section?


- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, March 08, 2017 8:37 AM
To: dhcwg <[e-mail]>
Cc: draft-ietf-dhc-sedhcpv6 authors <[e-mail]>
Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

Hi,
draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key cryptography to provide end-to-end security between DHCPv6 clients and servers. The mechanism provides encryption in all cases, and can be used for authentication based on pre-sharing of authorized certificates. This draft has started in 2013, but the whole DHCPv6 security saga is much longer and begins in 2008. This draft was submitted to IESG in mid-2015.
The guidance received was clear that  substantial changes are needed. As a result, "encrypt everywhere, authenticate if you can" approach was used.

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. Feel free to send nitpicks and minor corrections to the authors directly. This is a complex draft, so the chairs believe 3 weeks WGLC is in order. Please send your comments no later than March 29th. Bernie and I will determine consensus and will discuss during Chicago meeting as needed.

To initiate the discussion, I have two related questions. The chairs would love to hear your opinions on those.

1. The "encrypt everywhere" paradigm means that in deployments that do snooping on relay will break down. To solve this problem, we need a assignment notification mechanism, similar to the one described in draft-ietf-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years ago. This matter was discussed in Seoul and the minutes describe the conclusion as:

  The discussion gravitated towards not resurrecting until the sedhcpv6
  I-D progresses further. We will reevaluate this once sedhcpv6 is done.

Do you want the WG to resurrect agentopt-delegate a) now, b) when
sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we need a completely new draft and I'm volunteering to work on it.

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?

Title: Secure DHCPv6
Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang
Filename: draft-ietf-dhc-sedhcpv6-21
Pages: 31
Date: 2017-02-21
Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

Responses by March 29th are appreciated.

Thanks,
Bernie and Tomek

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg