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

[Lishan Li <[e-mail]>]

Hi, Bernie,

Thanks a lot for your valuable comments. For the details, please see inline.

Best Regards,
Lishan

2017-03-26 10:05 GMT+08:00 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.
>
[LS]: Sorry for the unclear expression. How about the following text?
The DHCPv6 message sent from the client is encrypted and then encapsulated
into the encrypted DHCPv6 message field according to the Encrypted-Data
content syntax defined in the RFC5652.


>
> 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?
>
[LS]: Yes. Will modify it.

>
> 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?
>
[LS]: Agree. Will modify it.

>
> 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.
>
[LS]: Yes, the server just need to keep one set for all clients.
How about the following modified text?
For client, it MUST remember about its own increasing number, which is
stored in the NUM.STO and sent to the server. And the client also MUST
remember about a server's increasing number, which is received from the
server and stored in the NUM.REC. And the client keeps a record of the
increasing number during the DHCPv6 configuration process with the DHCPv6
server.  And the client can forget the increasing number information after
the transaction is finished.  The client's initial locally stored
increasing number is set to zero.

For server, it MUST remember about its own increasing number, which is
stored in the NUM.STO and sent to the client. And the server also MUST
remember about a client's increasing number, which is received from the
client and stored in the Num.REC. The server just need to keep one
increasing number set for all clients.

>
> 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)"?
>
[LS]: Agree, will modify it.

>
> 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?
>
[LS]: Got it. Will modify it.

>
> Section 10
>
> There are now only three (not six) status codes.
>
[LS]: Will correct it.

>
> 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.
>
[LS]: Will correct it.

>
>
> Section 11
>
>    There are some mandatory algorithm for encryption algorithm in this
>
> Change (first) algorithm to algorithms? Or, change "are some" to "is a"
>
[LS]: Will change it.

>
>
>    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?
>
[LS]: If the encryption-key-tag is forged, then the server may cannot
decrypt it and drop the message.

>
>
> Some even more MINOR comments (these would perhaps improve readability but
> would likely be addressed by the RFC editor):
>
[LS]: Sorry for the poor expression. And thanks a lot your throughout
check. Will correct it in the next version.

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