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

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 8 Mar 2017 14:36:58 +0100

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 24 Mar 2017 17:24:56 +0000

Hi Tomek,

With apologies for the delayed response, see below:

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

a) now. What would be the reason for any delay?

If there is any assistance I could give to the effort I would be willing
to help.

Thanks - Fred
[email-masked]

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 26 Mar 2017 02:05:52 +0000

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:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, March 08, 2017 8:37 AM
To: dhcwg <[email-masked]>
Cc: draft-ietf-dhc-sedhcpv6 authors <[email-masked]>
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.

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:

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

Thanks,
Bernie and Tomek

---

From: Lishan Li <[email-masked]>
Date: Mon, 27 Mar 2017 12:33:02 +0800

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) <[email-masked]>:

> 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).
>
[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.

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

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

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

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

> Change DHCPv6-Response to Encrypted-Response.
[LS]: Will correct it.

> Change (first) algorithm to algorithms? Or, change "are some" to "is a"
[LS]: Will change it.

> Isn't this generally useless? As the message is encrypted, the validation
[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...").
>
>
> 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.
>
>
> 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).
>
> 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
>
> The guidance received was clear that  substantial changes are needed. As a
> result, "encrypt everywhere, authenticate if you can" approach was used.
>
> 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.
>
> 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:
>
> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 27 Mar 2017 14:07:46 +0000

Hi:

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.

BV> I assume this reference is to section 8 of RFC 5652. But now the question is whether anything further needs to be defined – for example, what (optional) attributes should be included? Perhaps as I’m not a security expert or have carefully reviewed RFC5652 and am taking a few things “out of content” when looking at it, but I think some clarity here may help in make sure this is easy to implement (especially for some of us that may not be experts in cryptography). This is a bit more complex than just taking the bytes of the client’s unencrypted message and the private key to encrypt (and placing that into the Encrypted-message Option), and taking the encrypted client’s message bytes (from a received Encrypted-message Option) and decrypting with the public key? You may want to think about whether perhaps specifying the details appropriate to DHCPv6 usage is appropriate – perhaps even in an appendix? RFC5652 talks about:

And there’s a lot about ASN.1 and OIDs in RFC5652, so are you pulling in all of this?

   The following object identifier identifies the encrypted-data content
   type:

      id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

   The encrypted-data content type shall have ASN.1 type EncryptedData:

      EncryptedData ::= SEQUENCE {
        version CMSVersion,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

   The fields of type EncryptedData have the following meanings:

      version is the syntax version number.  If unprotectedAttrs is
      present, then the version MUST be 2.  If unprotectedAttrs is
      absent, then version MUST be 0.

      encryptedContentInfo is the encrypted content information, as
      defined in Section 6.1<https://tools.ietf.org/html/rfc5652#section-6.1>.

      unprotectedAttrs is a collection of attributes that are not
      encrypted.  The field is optional.  Useful attribute types are
      defined in Section 11<https://tools.ietf.org/html/rfc5652#section-11>.

Probably section 6.1 is most applicable and there we have (eventually):

    EncryptedContent ::= OCTET STRING

Which may be all we really need?

And, if so, what is the value in referencing this RFC?

Again, I’m just trying to understand this more completely – what exactly is inside the Encrypted-message option?

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

BV> Here again, please be careful:

1.       If client always starts at 0, how does that help in preventing replay? And, this isn’t consistent with the server’s behavior above?

2.       If client doesn’t persist this, what happens if server has a lease for the client (and has retained the replay numbers) but the client released (or otherwise deleted the lease). Now when the client Solicits (encrypted), the server would report that this is a potential replay attach? I don’t think dropping this information “after the transaction is finished” is possible.

3.       For “The server just need to keep one increasing number set for all clients” – shouldn’t that be after the first sentence as this applies to NUM.STO; not NUM.REC?
Thus, I think the client must retain the number it last used with a server. This seems to be an issue for devices without persistent storage, so may require some further thought – or those devices cannot use increasing number?

And, I think both having to retain this forever would be a bad idea. I think one could provide for both clients and servers to “forget” any stored information after a period of time (perhaps this can be a fixed number, 30 days, or should be some multiple of the lease lifetime)?

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.

BV> Right, but isn’t that exactly what we would want? So, how is this bad?

BV> Re Security Considerations - A new comment from a conversation with Tomek (Tomek will hopefully comment more). I mentioned that I was concerned with the possibility of clients and servers getting “junk” is a security concern as someone could generate bad packets with encrypted data and send them to clients and servers in the hope to crash the either when they try to decrypt and then process junk. Tomek suggested we might want to think about whether to add some magic value to the first few bytes of a message before encrypting it and then the decrypter can check those first few bytes to see if they are value and discard the message if not. Perhaps the encoding from RFC5652 would accomplish this if we are using more than just the encryptedContent? Anyway, something to think about.

Again, thanks for your continued efforts on this document!

-          Bernie

From: Lishan Li <[email-masked]>
Date: Monday, March 27, 2017 at 12:33 AM
To: Bernie Volz <[email-masked]>
Cc: Tomek Mrugalski <[email-masked]>, "[email-masked]" <[email-masked]>, draft-ietf-dhc-sedhcpv6 authors <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

Hi, Bernie,

Best Regards,
Lishan

2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>:
Hi:

So here goes ...

Section 6:

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:

Section 8

Section 9.1:

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.

Section 9.2:

Section 10

Section 10.2

Section 11

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:

How about:

Section 7:

Section 10.1.1

Section 11

Lower case "It"?

General

- Bernie

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

Title: Secure DHCPv6

Thanks,
Bernie and Tomek
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Mon, 27 Mar 2017 21:06:23 -0700

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

> your opinion whether this draft is ready for publication.

See below.

> 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

---

From: Lishan Li <[email-masked]>
Date: Thu, 30 Mar 2017 16:49:13 +0800

2017-03-27 22:07 GMT+08:00 Bernie Volz (volz) <[email-masked]>:

>       defined in Section 6.1
> <https://tools.ietf.org/html/rfc5652#section-6.1>.
>
>
>
>       defined in Section 11
> <https://tools.ietf.org/html/rfc5652#section-11>.
>
>
>
[LS]: Yes, the reference is section 8 of RFC5652.
In the before version, Stephen suggested us to illustrate the format of the
encrypted message data. He suggested to add the reference of RFC5652 for
it.
But in fact, I don't know much about details of the draft.

> 1.       If client always starts at 0, how does that help in preventing
> replay? And, this isn’t consistent with the server’s behavior above?
>
[LS]: For the first time that the client receives the increasing number,
the client cannot compare it with the local number, and just to store it.

> 2.       If client doesn’t persist this, what happens if server has a
> lease for the client (and has retained the replay numbers) but the client
> released (or otherwise deleted the lease). Now when the client Solicits
> (encrypted), the server would report that this is a potential replay
> attach? I don’t think dropping this information “after the transaction is
> finished” is possible.
>
[LS]: Yes, it is better for the client to retain the number it last used
with a server. For the devices without the persistent storage, the initial
value of the increasing number is zero. After checking the increasing
number in the Reply message, the NUM.STO is set to the NUM.REC. When
sending the Solicit message, the increasing number is larger than the
NUM.STO. So, the server will not report that this is a potential replay
attack.

> 3.       For “The server just need to keep one increasing number set for
> all clients” – shouldn’t that be after the first sentence as this applies
> to NUM.STO; not NUM.REC?
>
> Thus, I think the client must retain the number it last used with a
> server. This seems to be an issue for devices without persistent storage,
> so may require some further thought – or those devices cannot use
> increasing number?
>
[LS]: Agree, the client MUST retain the increasing number it last used with
a server.

>
>
> And, I think both having to retain this forever would be a bad idea. I
> think one could provide for both clients and servers to “forget” any stored
> information after a period of time (perhaps this can be a fixed number, 30
> days, or should be some multiple of the lease lifetime)?
>
[LS]: So we can recommend a lifetime of the increasing number for the
client and server, such as 30 days. Could you please check my understanding
correct?

>
> BV> Re Security Considerations - A new comment from a conversation with
> Tomek (Tomek will hopefully comment more). I mentioned that I was concerned
> with the possibility of clients and servers getting “junk” is a security
> concern as someone could generate bad packets with encrypted data and send
> them to clients and servers in the hope to crash the either when they try
> to decrypt and then process junk. Tomek suggested we might want to think
> about whether to add some magic value to the first few bytes of a message
> before encrypting it and then the decrypter can check those first few bytes
> to see if they are value and discard the message if not. Perhaps the
> encoding from RFC5652 would accomplish this if we are using more than just
> the encryptedContent? Anyway, something to think about.
>
[LS]: Agree. Perhaps the encoding from RFC5652 solves this problem.
I think that it may be a general problem for all encryption protocol.

> Again, thanks for your continued efforts on this document!
[LS]: As the author of the draft, I have the responsibility to work on it.
Thanks a lot for your continued guidance on this.

Best Regards,
Lishan

> *From: *Lishan Li <[email-masked]>
> *Date: *Monday, March 27, 2017 at 12:33 AM
> *To: *Bernie Volz <[email-masked]>
> *Cc: *Tomek Mrugalski <[email-masked]>, "[email-masked]" <
> [email-masked]>, draft-ietf-dhc-sedhcpv6 authors <
> [email-masked]>
> *Subject: *Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by
> March 29th
>
>
>
> Hi, Bernie,
>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 30 Mar 2017 14:34:41 +0000

Another issue to consider from speaking with Eric Vyncke last evening:

- What about verifying the certificate's time? A client might not have current time and so may not be able to determine if certificate has expired?

- Bernie (from iPhone)

On Mar 30, 2017, at 3:49 AM, Lishan Li <[email-masked]<mailto:[email-masked]>> wrote:

2017-03-27 22:07 GMT+08:00 Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>:
Hi:

[LS]: Yes, the reference is section 8 of RFC5652.
In the before version, Stephen suggested us to illustrate the format of the encrypted message data. He suggested to add the reference of RFC5652 for it.
But in fact, I don't know much about details of the draft.

[LS]: For the first time that the client receives the increasing number, the client cannot compare it with the local number, and just to store it.

[LS]: Yes, it is better for the client to retain the number it last used with a server. For the devices without the persistent storage, the initial value of the increasing number is zero. After checking the increasing number in the Reply message, the NUM.STO is set to the NUM.REC. When sending the Solicit message, the increasing number is larger than the NUM.STO. So, the server will not report that this is a potential replay attack.

3.       For “The server just need to keep one increasing number set for all clients” – shouldn’t that be after the first sentence as this applies to NUM.STO; not NUM.REC?
Thus, I think the client must retain the number it last used with a server. This seems to be an issue for devices without persistent storage, so may require some further thought – or those devices cannot use increasing number?
[LS]: Agree, the client MUST retain the increasing number it last used with a server.

And, I think both having to retain this forever would be a bad idea. I think one could provide for both clients and servers to “forget” any stored information after a period of time (perhaps this can be a fixed number, 30 days, or should be some multiple of the lease lifetime)?
[LS]: So we can recommend a lifetime of the increasing number for the client and server, such as 30 days. Could you please check my understanding correct?

[LS]: As the author of the draft, I have the responsibility to work on it. Thanks a lot for your continued guidance on this.

Best Regards,
Lishan
From: Lishan Li <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 27, 2017 at 12:33 AM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>
Cc: Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, draft-ietf-dhc-sedhcpv6 authors <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

Hi, Bernie,

Best Regards,
Lishan

So here goes ...

Section 6:

Section 7:

Section 8

Section 9.1:

Section 9.2:

Section 10

Section 10.2

Section 11

Section 6:

How about:

Section 7:

Section 10.1.1

Section 11

Lower case "It"?

General

- Bernie

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

Title: Secure DHCPv6

Thanks,
Bernie and Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 30 Mar 2017 14:37:44 +0000

Regarding RFC5652, you will need to work with others to determine what pieces are applicable - perhaps check in with Stephen to get more clarity on what he intended? Perhaps Jinmei or Francis Dupont has some suggestions?

- Bernie (from iPhone)

Best Regards,
Lishan

Hi, Bernie,

Best Regards,
Lishan

So here goes ...

Section 6:

Section 7:

Section 8

Section 9.1:

Section 9.2:

Section 10

Section 10.2

Section 11

Section 6:

How about:

Section 7:

Section 10.1.1

Section 11

Lower case "It"?

General

- Bernie

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

Title: Secure DHCPv6

Thanks,
Bernie and Tomek

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Mar 2017 10:00:36 -0500

> - What about verifying the certificate's time? A client might not have current time and so may not be able to determine if certificate has expired? 

Clients that don't have the current time don't get very good security.   I don't know of a way to fix this.   At a minimum, a client with no clock and stable store should at least remember its last boot time every so often (maybe not every boot, to avoid flash wear, but maybe at least once a month).   This will make it difficult to replay really old certs.   But it's pretty thin.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 30 Mar 2017 17:21:30 +0200

Sorry for late comment but this just caught my attention.

>>     BV> Re Security Considerations - A new comment from a
>>     conversation with Tomek (Tomek will hopefully comment more). I
>>     mentioned that I was concerned with the possibility of clients
>>     and servers getting “junk” is a security concern as someone could
>>     generate bad packets with encrypted data and send them to clients
>>     and servers in the hope to crash the either when they try to
>>     decrypt and then process junk. Tomek suggested we might want to
>>     think about whether to add some magic value to the first few
>>     bytes of a message before encrypting it and then the decrypter
>>     can check those first few bytes to see if they are value and
>>     discard the message if not. Perhaps the encoding from RFC5652
>>     would accomplish this if we are using more than just the
>>     encryptedContent? Anyway, something to think about.
>>
If someone deliberately wants to make bad packets with the purpose of
causing problems, they would be smart enough to add the same magic
number? Knowing the encryption algorithms would allow more deliberate
attempts to cause overflow etc.

I don't see any other method than careful programming and careful
testing with deliberate intent to find weak spots.

If we talk about noise or other non-intentional bad/random packet, then
a magic number will help.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 30 Mar 2017 13:00:33 -0500

I have reviewed the draft and in my opinion -21 is in great overall
shape. The text reads so much better, the concept is clearly explained
early and the whole text fits together well. I do have many comments,
but great majority of them are clarifications and editorial corrections.
Good work, authors!

Ok, let's start with easy ones.

idnits. There are a number of idnits errors and warnings: 3 errors (**),
0 flaws (~~), 8 warnings (==), 5 comments (--).. Please fix them. Ping
me off the list if you need a little help with idnits tool.

This draft defines a set of recommendations for secure environment. It
is not expected to be used by all DHCP implementations is every
deployment, just those who are interested in improved security. In
certain way it is very similar to anonymity profile. Anonymity profile
defined set or rules that are not expected to be used by all DHCP
implementations in every deployment, just those who are interested in
improved privacy. So maybe it should be called Security Profile for
DHCPv6? I think this approach does not change anything from technical
perspective, but simply frames the solution better. Described that way
it may also be easier to accept to people who may afraid we want to
force everyone to encrypt everything everywhere. It's just a suggestion
to consider, I don't insist on it if authors or the WG disagree.

I like section 5, especially 5.1 and 5.2 a lot. It's a great two-page
intro to the concept.

Section 5.3
nit: mainly a algorithm => mainly an algorithm

Section 5.4 should also discuss the problem with Confirm message
mentioned earlier by Jinmei.

Section 5.5
nit: In some scenario => In some scenarios

Section 6
nit: is a Increasing-number option => is an Increasing-number option

Section 6: Is Advertise protected as well? I think it definitely should
be to the maximum extent possible. Once the initial info-request/reply
is completed, the next step for the client is to send Solicit wrapped in
Encryption-Query. The server will reply with Advertise wrapped in
Encryption-Response. At this stage the received Advertise can be
validated. Maybe not all of the checks are possible yet for Advertise,
because of not all necessary information is available yet (e.g. there's
not possible to do the increasing number check as this is the first
packet coming back and the client doesn't have previous value to check
it against), but some checks are definitely applicable (e.g. drop
because signature is missing, multiple signatures or certificate missing).

Unless there's a good reason to not do it, the rules described in on
page 9 should apply to both Advertise and Reply.

"beat out a busy "real" server" => "beat out a busy legitimate server"

There is this text: "The Certificate option MUST be constructed as
explained in Section 10.1.2.", but I don't see any "client MUST send
Certificate option". It's also not shown on Figure 1. Yet, the server
section says that incoming messages without Certificate option are to be
dropped. This should be clarified.

It's a matter of preference, but I think Section 6 is too long and
should be split into several sub-sections. When someone references it
("see Section 6"), it's difficult to find what specific parts of the
text is being pointed out to.

"the subsequent encrypted DHCPv6 message sent from the client can also
contain the Increasing-number option to defend against replay attack.".
Is there a reason why "can" is used, not SHOULD or even MUST?

"If the transaction-id is 0, the client also try to decrypt it." Two
comments about this. First, what is the client supposed to decrypt - the
transaction-id field or the whole message? Second, what should the
client do if it's not 0?

"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." That's a good text, but it doesn't belong in the place where
it is now. It should be moved to separate paragraph or even separate
section. You may also consider adding something like "Secure DHCPv6 can
maintain multiple DHCPv6 sessions, but such scenario is not considered
here for clarity reasons."

"The encryption text SHOULD...". What is encryption text? Did you mean
encrypted message or the message to be encrypted?

nit: "as explain in [RFC5652]" => "as explained in [RFC5652]"

"After the decryption, it handles the message as per 3315". I'm not a
security expert by any stretch of that word, so excuse my naive
question. Anyway, can you always detect that the decryption was a
success or failure? Some decryption techniques will produce output, even
when the key is incorrect, but the output will be an almost random
garbage. Can the mechanism defined in RFC5652 always reliably conclude
the decoding operation was success/failure? If not, I'm afraid that
asking clients and server to decode random garbage will break some
implementations.

If the decryption algorithm cannot give definite success/fail answer,
there's a solution I have in mind. You may add a magic cookie (a well
known value of perhaps 4 bytes) at the beginning before encrypting the
actual message and encrypt (cookie,message) tuple. Then the first check
after decryption the receiver would do is to check if the first 4 bytes
match the cookie value. If not, then throw away the whole packet without
trying to parse any of it. I discussed the concept with Bernie and he's
in favour of it. Also discussed with Jinmei and he's against it. Sten
posted his comment against it, but I'm not sure if Bernie's description
of the concept was accurate enough. Any other thoughts on this?

"switch to other DHCPv6 server if it has another one." => "switch to
other DHCPv6 server if available."

The text uses "one and only one" several times. You may consider
replacing it with "exactly one". It reads easier that way, but I admit
it's a matter of preference, so it's just a suggestion.

"The DHCPv6 server drops the message that is not for it, thus not paying
cost to decrypt messages."
=> "The DHCPv6 server drops the message if the value of Server
Identifier option does not match its own, thus not paying the cost of
message decryption."

"If the server cannot find the corresponding private key of the key tag
or the corresponding private key of the key tag is invalid for
decryption, then the server drops the received message." Shouldn't the
server send back AuthenticationFail status? The benefit is that the
client could try again and use a different certificate.

"For the signature failure, the server SHOULD send an encrypted Reply
message with an UnspecFail (value 1, [RFC3315]) error status code to
the client." Why use UnspecFail, if there's SingatureFail code for it?

General comment: "cert" should be replaced with "certificate". Even
though everyone understands this jargon, it should be avoided in formal
documents.

Section 9.1:
nit: "The server should keep a record of the increasing number forever."
Nothing is eternal, so I don't like the word forever. It would be better
to say the server must be able to retain the increasing number across
restarts.

Remove "And " at the beginning of two sentences in first paragraph.

Section 9.2:
Thanks a lot for including the code. It's very helpful. However, please
update the comments that mention RDATA, DNSKEY RR and RDLENGTH. That way
fewer people will realized where it was borrowed from :)

Nit: some of the values to be assigned by IANA are boilerplated as
TBD[number] and some as TBA[number]. Typically it's TBD[number].

Section 10.1.1

The text describing EA-id List could use an update. First, it's not
clear what EA stands for (it is explained further down, but requires a
bit of hopping around the text). I would replace "EA-id: The format of
the EA-id List field is shown in Figure 3." with "EA-id List: Contains a
list of supported Encryption Algorithm identifiers. The format of the
EA-id List field is shown in Figure 3." Similar text should be added for
SHA-id List ("Contains a list of supported Signature/Hash Algorithm
pairs.").

Nit: I'm not sure, but it looks like you put the whole description of
EA-id into the Figure 3. It's better to have it as text outside of
Figure. That's probably also one of the reasons why idnits is unhappy.

10.1.2
"The Certificate option carries the certificate of the client/server,
which is contained in the Reply message." This is confusing. I could
easily misinterpret this as "server is supposed to send client
certificate in Reply message" or even "Client can send Reply message
with a certificate". It would be better to say "The Certificate option
carries the certificate of the sender. It can be included by the client
(see Section 6) and by the server (see Section 7)." Also, see my earlier
comment about Section 6 not explicitly saying if/when the Certificate
option is to be sent.

Sections 10.1.*
As a convenience to the reader, I would add a text similar to "The
Algorithm option is sent by the client, as described in Section 6.".
Similar texts should be added in other sections that describe the
options. It can be confusing to understand who sends what, so such
pointers are useful in my opinion. This applies to all sections that
describe options.

Section 10.2
"share the following format:" => "share the standard format of DHCPv6
messages:".

Section 11
"There are some mandatory algorithm for encryption algorithm in this
document.  It may be at some point that the mandatory algorithm is no
longer safe to use." => "There are some mandatory algorithms specified
in this document.  It may be at some point that the mandatory algorithm
is no longer safe to use. To mitigate this problem, an extension
mechanism was defined that allows usage of new encryption, signing and
hash algorithms."

Another problem that should be mentioned is that secure traffic cannot
be snooped by the relay agents. This is of crucial importance for
networks that use PD and use relay snooping. It would be even more
appropriate to create separate section called Deployment Considerations
for it. If the RAAN draft is resurrected before sedhcpv6 reaches IESG
(it should), adding text similar to "This issue will be addressed in
future IETF work and add reference to
draft-ietf-dhc-dhcpv6-agentopt-delegate).

Another possible topic for discussion in deployment considerations would
be how to do Rebind. My understanding is that it would work as long as
both servers would use the same certificates. This explanation is buried
deep in section 5.4, but it's probably useful to mention it explicitly
(or have a pointer to 5.4) if you decide to create deployment
considerations section.

Section 12
Do you (that's a broad question to the WG, not just authors) think it
would be useful to add extra column to the new registries, specifying
whether the protocol is mandatory, optional or deprecated? We would
start with one mandatory in each registry and all other entries being
optional. When new protocols are defined in the future and flaws in
existing ones are discovered, we could publish short documents to easily
update the current state of affairs. It would also correlate well with
the text you have in section 11.

I agree with Jinmei-san that the Confirm message problem is something
that should be tackled. I don't have any ready to use solution for you,
but going in the direction that Jinmei suggested (doing separate
inf-request/reply to discover available servers) seems the best way.

Finally, to answer my own question I think dhc-dhcpv6-agentopt-delegate
should be resurrected right now, so sedhcpv6 could reference to it, when
it discusses the issue with snooping. This is something I hope to
discuss in couple hours during meeting.

Ok, that's it.
Tomek