Subject: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Jan 2016 15:10:15 -0800

I've read this version of draft.  While I happen to be listed as a
co-author, I was not really involved in this revision process, so I'm
basically making these comments as a third-party reader.

First, I have some higher-level points to discuss:

- this protocol changes DHCPv6 message exchanges quite substantially:
  previously, the client first sends a Solicit message, gets possibly
  multiple Advertise messages, chooses the server (= sender of one of
  the Advertises) that would be best for the client, and then sends a
  Request to that chosen server.  Now the server selection is done at
  the key exchange phase (the initial Information-request and Reply
  exchange), and the Solicit can be sent only to a single server.  If
  the client doesn't like the Advertise it could restart the whole
  process, but it will be more expensive, and there's no guarantee
  that other servers can provide a better Advertise.

  One might argue that it's okay as "secure DHCPv6" is an "optional"
  extension.  But, with keeping in mind that the current IETF trend is
  to make everything privacy-aware (often by making everything
  encrypted), I'd personally say we should consider it to be the
  standard mode of DHCPv6 operation even if users can still disable
  it.  From this point of view, I think we should either
  A. make the server selection behavior more compatible with the
     pre-encryption protocol, or
  B. accept we give up the previous server selection feature for
     privacy (after careful assessment of its effect and with clear wg
     consensus), and explicitly note that.  we might even have to
     reflect that in rfc3315bis.

- As encryption is now mandatory, I now wonder whether we need a
  separate "signature" at all.  Except for the signature in the reply
  to the initial Information-request, the explicit signature doesn't
  seem to provide any additional integrity or authentication.  And, as
  we now don't allow TOFU for authentication (i.e., we should validate the
  certificate out-of-band anyway, and that's almost the only important
  content of this reply), the signature in the first Reply wouldn't be
  much useful either.  So we might consider simplifying the protocol

- Slightly related to the previous point, this draft doesn't talk
  about encryption algorithms, let alone whether/how to negotiate the
  encryption algorithm.  (Aside from whether we need a separate
  'signature') Perhaps it implicitly assumes to use the "signature
  algorithm" for encryption, too, but, if so, I think it should
  explicitly say so.

- This protocol uses the server DUID as the identifier of the server
  key (pair), and (implicitly) assumes the client only has one key
  (pair).  Is that okay?  Don't we need a separate key ID value so we
  can identify the key to be used for decryption without actually
  trying to decrypt the message with all possible keys?  (In the case
  of client this might be trickier since the 'key ID' can reveal the
  identify of the client).

- The 'public key option' has been removed in this version.  I
  probably missed some part of the past discussions, but did we make
  that decision?  What's the rationale of the removal?

- The "security issues" and "applicability" sections (especially the
  latter) look still weak/insufficient to me.  I'll make some more
  specific comments below.

- Related to the previous point, what (will) happened for the separate
  threat analysis/usage document?  If the plan was to move all
  difficult discussions regarding the "security issues" to the
  separate document, we should also see it with this protocol
  document.  (In my understanding) the latter can't move forward
  itself otherwise.

Some specific comments on the draft text follow:

- Section 4

   authentication method.  However, this method provides little message
   integrity or source integrity check, and it protects only the
   Reconfigure message.  This key is transmitted in plaintext.

  I'm not sure if I get the phrase "this method provides little
  message integrity or source integrity check".  Does it try to say
  "*Because* the key is transmitted in plaintext"?

- Section 4

   IETF has expressed strong agreement that PM is an attack that needs
   to be mitigated where possible in [RFC7258].

  I think the acronym "PM" should be explicitly introduced when
  "pervasive monitoring" first appears (in Introduction).

- Section 5.1

   [...]  Depending on
   its policy, it can choose to connect repeat the server discovery
   process after certain delay or attempt to connect to a different
   network.

  I'm not sure what this 'connect' means.  Does it intend to say cases
  like a smartphone/laptop trying to find a wifi base station?

- Section 5.3: what about the server-to-client case?  Clients are
  expected to rely on the selection in the initial
  Information-request/Reply exchange?

   If the recipient does not support the algorithm used by the sender,
   it cannot authenticate the message.  In the client-to-server case,
   the server SHOULD reply with an AlgorithmNotSupported status code
   (defined in Section 10.3).  Upon receiving this status code, the
   client MAY resend the message protected with the mandatory algorithm
   (defined in Section 10.1.2).

- Section 5.4: in general, I think this section is still quite weak
  and/or insufficient.  First, the current text reads as if PKI is
  (readily) usable in enterprise networks, yet it dismisses its
  deployment as out-of-scope.  I don't think this would address
  concerns/questions raised by external reviewers.

  My understanding of the external feedback and our followup
  discussions is that one sure way to deploy this protocol in
  enterprise network is to almost manually configure the clients with
  the server certificate and configure the server with clients
  certificates.  But we'll then have to explain what's the advantage
  of this new protocol against the RFC3315 security mechanism since
  Section 4 of this document states manual configuration is one major
  flaw of the RFC3315 mechanism.  My personal answer to this question
  is that the public-key based approach is slightly securer in cases
  such as that where clients keys are quietly stolen by an attacker
  (so they can pretend to be a valid client later).

  On top of such realistic discussions, I think we can also mention
  the use of PKI as a possibility of making the configuration (much)
  less manual.  But since it would require answering many difficult
  questions, IMO we should be honest to say its feasibility is unclear
  right now and subject to future study and development.

  Also, if we revise this section as suggested above, Section 4 will
  have to be adjusted, too, since we can't (yet) claim secure DHCPv6
  solves the "flaws" of the existing mechanisms.

- Section 5.4:

   [...]  In enterprise network, the security policy is
   strict and the clients are stable terminals.  The PKI model is used

  What does 'stable' mean?  A desktop PC would be considered a "stable
  terminal", but what about laptops?  How about smart phones connected
  to the enterprise network based on the BYOD policy?

- Section 6

   For the security DHCPv6 client, it must have a public certificate.

  What does "*public* certificate" mean?  Does that mean it's not
  "private"?  Same for Section 7.

- Section 6

   [...]  The Information-request message MUST NOT include any
   option which may reveal the private information of the client, such
   as the client identifier option.

  I suggest adding "...or the certificate option".

- Section 6

   non-security options assigned to it.  The Option Request option in
   the Information-request message MUST contain the option code of
   certificate option, signature option, timestamp option, and server
   identifier option.

  Should we really need to include all of these?  The certificate
  option should surely be specified, but the need for the others seem
  to be almost automatically derived from the specification.

- Section 6

   [...] The client SHOULD also use the same algorithms in the
   return messages.

  It's not very clear to me what "return messages" mean (as the client
  is usually the initiator of DHCP exchanges).  Perhaps "in subsequent
  messages (of the same DHCPv6 session)"?

- Section 6

   [...]  Depending on its policy, it can choose to connect using
   plain, unencrypted DHCPv6, repeat the server discovery process after
   certain delay or attempt to connect to a different network.

  What "connect to a different network" means isn't very clear to me
  (see also the same sense of comment on Section 5.1)

- Section 6

   For the received Encrypted-Response message, the client extracts the
   encrypted-message option and decrypts it using its private key to
   obtain the original DHCPv6 message.

  What if the client has more than one key pair (see also the higher
  level comment above)?  Is it assumed to associate transaction-id to
  a particular key?

- Section 6

   o  Upon receiving a SignatureFail error status code, the client MAY
      resend the message following normal retransmission routines
      defined in [RFC3315].

  What's the rationale of this behavior?

- Section 7

   If the server does not send the timestamp option, the client ignores
   the timestamp check and verifies the signature.  If there is a [...]

  I don't understand the role of the first sentence in this context.

- Section 7

   [...]  Depending on server's local policy, the message without a
   Timestamp option MAY be acceptable or rejected.  If the server
   rejects such a message, a TimestampFail error status code, defined in
   Section 10.3, should be sent back to the client.  [...]

  To be sure: is the TimestampFail supposed to be returned when a
  message from the client doesn't have Timestamp but the server wanted
  it?

- Section 8

   [...]  Actually, by definition in this
   document, relay agents SHOULD NOT add any secure DHCPv6 options.

  Why is this a "SHOULD NOT", i.e. can't this be "MUST NOT"?

- Section 10.1.2

   Note: if both signature and authentication option are present,
   signature option does not protect the Authentication Option.  It

  Should we still worry about it?  The only possible reason for having
  both that I can see is to allow a newer client implementation to
  work with both new and old server implementations.  But now that the
  message is encrypted in a way that older implementations don't
  understand, it's completely impossible anymore.  I think we can now
  simply say Authentication Option shouldn't be used with Secure
  DHCPv6 (and if it's used the behavior is undefined).

- Section 10.1.3

   Timestamp      The current time of day (SeND-format timestamp
                  in UTC (Coordinated Universal Time). It can reduce
                  the danger of replay attacks.

  I'd add a reference to the SeND RFC here.

- Section 10.2.1

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |               transaction-id                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                             DUID                              .
     |                           (variable)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Why is the DUID dedicated field, instead of using the server
  identifier option?  There are other types of messages that require a
  server identifier option (e.g., RENEW), but they don't make it a
  separate field.  I don't see any reason how this case is different,
  and using a separate format will make implementations unnecessarily
  complicated.

Editorial nits:

- Section 4: this sentence at least misses a period (I'm not sure if
  it's terminated with 'improved' or some other text was expected
  after that).

   [...]  The
   basic DHCPv6 specification [RFC3315] defines security mechanisms, but
   they have significant flaws and can be improved

- Section 5.1: s/authentication, MUST/authentication MUST/

   key.  The message that fails client authentication, MUST be dropped.
   And the server sends the corresponding error status code to client.

- Section 6: s/security/Secure/

   For the security DHCPv6 client, it must have a public certificate.

- Section 7: s/pre-configured/pre-configured with/

   The server may be pre-configured a public key certificate, which is

- Section 7: s/replies/replies with/ (same for some other use cases of
  'reply')

   server authentication information, it replies the Reply message to

- Section 8 s/describes/described/

   [...]  The unknown
   messages MUST be forwarded as describes in [RFC7283].

- Section 10.1.2 s/be/be in/

   [...]  The signature option could
   be any place within the DHCPv6 message while it is logically created

- Section 10.1.2 s/chose not/chose not to/ Also, this sentence(-like)
  seems grammatically broken but I have no idea about how to fix it.

   changing auth option, the authors chose not include authentication
   option in the signature.

---

From: Lishan Li <[email-masked]>
Date: Sun, 17 Jan 2016 17:11:18 +0800

Dear Jinmei,

Thanks a lot for your valuable comments. For the detailed replies, please
see inline ( these lines start with [LS] ).

Best Regards,
Lishan

2016-01-08 7:10 GMT+08:00 神明達哉 <[email-masked]>:

> [LS]: In my opinion, we should give up the previous server selection
feature for
privacy. Compared with rfc3315 and rfc3315bits, secure DHCPv6 is another
mode. rfc3315bis is clear-text mode. And the secure DHCPv6 is secure mode
which achieves authentication and encryption. The server selection feature
and configuration process are all different. And I think it is not
necessary
to reflect the character of secure DHCPv6 mode in rfc3315bis. Looking
forward
to your further guidance.

>   much useful either.  So we might consider simplifying the protocol

[LS]: In the current version, the client-to-server and server-to-client
both send the certificate option, signature option and timestamp option.
I think that only the server-to-client case MUST contain the signature
option and timestamp option.
In the server-to-client case, the signature and timestamp option in
the Reply message is used to protect the message integrity. So it is
better to remain the timestamp and signature option.
In the client-to-server case, the certificate option is contained in
the encrypted Solicit/Information-request message. Because the message
is encrypted, there is no need to contain the signature and timestamp
option to protect the message integrity.
What do you think of it?

> [LS]: The encryption algorithm need to be added. I will try to add
it in the next version.

> [LS]: I think we can use the message transaction-id as the identifier of
the server's public key for encryption, and the client's private key
for decryption. What do you think of it?

> [LS]: In the current version, TOFU is out of scope. The client and server
use  certificates for authentication, not public key. So I think the
certificate
option is enough. The public key option is removed.

> [LS]: we have updated a new version of the secure DHCPv6 deployment.
I wish you can give some comments on the secure DHCPv6 deployment draft.
Thanks in advance.

Some specific comments on the draft text follow:
> [LS]: How about the following text:
[...]  However, this method provides little message integrity or source
integrity check, and it protects only the Reconfigure message. In addition,
the key is transmitted in plaintext to the client in earlier exchanges.
[...]

- Section 4
> [LS]: Will correct it.

> [LS]: According to Bernie's comment, we have changed this sentence as
follows:
Depending on its policy, it can choose to repeat the server discovery
process after certain delay or attempt to use an unsecured DHCPv6 server.

> [LS]: In the next version, only in the server-to-client case, the server
will send the Reply message with signature and timestamp option to the
client for server authentication.
So, how about replacing with the following text:
If the client does not support the hash and signature algorithms used by
the server, the Reply message SHOULD be dropped. If both hash and signature
algorithms are supported, the client then checks the authority of this
server. The client SHOULD also use the same algorithms in the subsequent
messages.

> [LS]: How about the following "applicability" section:
Secure DHCPv6 is applicable in environments where physical security
on the link is not assured and attacks on DHCPv6 are a concern, such
as enterprise networks. In enterprise networks, the DHCPv6 clients
are manually pre-configured with the trusted servers' certificates to
achieve server authentication. In addition, the DHCPv6 server is
pre-configured with the trusted clients' certificates to verify the client's
identity. After the mutual authentication, the DHCPv6 message is encrypted
 with the recipient's public key, which is contained in the certificate.
The use of PKI as a possibility of making the configuration less manual.
However, its feasibility is unclear right now and subject to future study
and development.

And we supply the following text in section 4:
The public-key based approach proposed in this document is slightly
securer in some cases. For example, if the client's key is quietly
stolen by an attacker, then the attack can pretend to be a valid client
later.

> [LS]: Will correct it. public certificate -> certificate.

> [LS]: Will correct it.

> [LS]: The signature option and timestamp option are used for the message
integrity check. The Reply message is transmitted in clear text. So in
order to protect the Reply message integrity, I think the timestamp
and signature option MUST be contained.

> [LS]: Have corrected it. return messages -> subsequent messages

>   (see also the same sense of comment on Section 5.1)

[LS]: According to Bernie's comment, we have changed this sentence as
follows:
Depending on its policy, it can choose to repeat the server discovery
process after certain delay or attempt to use an unsecured DHCPv6 server.

- Section 6
> [LS]: Yes. In my option, the particular key is associated with
transaction-id.
What is your opinion? Looking forward to further guidance.

- Section 6
> [LS]: In the new version, the client will not send the signature option and
timestamp option. So we will delete these sentence.

- Section 7
> [LS]: Will delete the first sentence in the next version.

> [LS]: Yes. Maybe the above sentences are not clear. How about the following
sentences:
[...]  Depending on server's local policy, the message without a
Timestamp option MAY be accepted or rejected.  If the server
rejects such a message without Timestamp option, then a TimestampFail
error status code, defined in Section 10.3, should be sent
back to the client.  [...]

- Section 8
> [LS]: Agree. Will correct it.

> [LS]: I agree. So we replce this section with the following sentences:
If the Secure DHCPv6 is applied, then the Authentication Option shouldn't
be used.

- Section 10.1.3
> [LS]: Have added a reference: Section 5.3.1, [RFC3971].

> [LS]: Have modified it. In the new version, the diagram should just have
basic
client format (see RFC 3315, Section 6) and then text to specify that it
MUST contain a Server Identifier option and an Encrypted-message option.

Editorial nits:
>
> Thanks a lot for the throughout review. I will correct the editorial nits
in the next
version.

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

---

From: 神明達哉 <[email-masked]>
Date: Mon, 18 Jan 2016 10:42:13 -0800

I'm going to answer one specific point first, as I think that's most
substantial and requires explicit attention from other wg members.

At Sun, 17 Jan 2016 17:11:18 +0800,

> to your further guidance.

This basically seems to be what "one might argue" in my original
comment, so, obviously, I personally disagree on that rationale.  But
I wouldn't be surprised if the wg reaches to a different consensus
than my personal opinion, so I suggest you start a separate discussion
on this to form the consensus.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 18 Jan 2016 11:08:00 -0800

At Sun, 17 Jan 2016 16:52:38 +0800 (CST),

> option to protect the message integrity.

Maybe my points weren't clear enough.  First off, I didn't talk about
timestamp at all; let's focus on the signature option.  Secondly, I
don't see why encryption is not enough in the server-to-client case
for message integrity.

> for decryption. What do you think of it?

It's probably okay.  I think it should be described more explicitly.

> use  certificates for authentication, not public key. So I think the certificate

I don't understand that.  We should still be able to manually
configure public keys on clients and servers (see also the
applicability discussion), so simply because we removed the TOFU mode
shouldn't me we should remove the public key option.

> the key is transmitted in plaintext to the client in earlier exchanges.

This one still has the same problem.  Why does this method
(=Reconfigure Key Authentication Protocol) provide little message
integrity or source integrity?

> server. The client SHOULD also use the same algorithms in the subsequent

Dropping the message is fine, but then what?  Should the client keep
waiting for an expected reply and then possibly retransmit its message?

> >  and/or insufficient. [...]
>
> >

I'd first like to know whether we (the wg in general including
yourself) agree on my points and understanding of previous feedback.
On top of that, I'll probably offer my own proposed text on these.

> >  to the enterprise network based on the BYOD policy?

This point isn't answered.

> and signature option MUST be contained.

We are probably talking about different things.  My question and point
are whether timestamp and signature are specified in the "option
request option".  Your response doesn't seem to answer that point.

> [LS]: Yes. In my option, the particular key is associated with transaction-id.

See above.
> timestamp option. So we will delete these sentence.

Deleting it is probably fine, but it doesn't answer my point.  We'll
still need to answer what the client should do if the server indicates
a failure in decryption (which is equivalent to SignatureFail).

> back to the client.  [...]

Doesn't the original text (also) cover the case where Timestamp is
included but the check on it fails?  If so, the new text now loses its
original sense.

> If the Secure DHCPv6 is applied, then the Authentication Option shouldn't

It should also describe the rationale.  Also, we might consider using
an RFC2119 keyword, either SHOULD NOT or MUST NOT.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Thu, 21 Jan 2016 23:27:03 +0800

Dear Jinmei,

Please see inline.

[LS]:In the server-to-client case, the Reply message is transmitted in
cleartext not encryption, which contains the server's certificate
information.
So I think that it is better to contain the signature option for the Reply
message integrity check.
Looking forward to your further guidance.

> [LS]: Will add the explicit description.

> [LS]: If the device is pre-configured with public key not certificate, it
can
generate the self-signed certificate for authentication. So, I think that
the certificate option is enough for authentication.
Looking forward to your further guidance.

> [LS]: The authentication mechanism defined in RFC3315 can provide for the
authentication of the client and server, and for the integrity of messages
delivered between DHCPv6 clients and servers.
So, how about the following text:
[...]  However, this method protects only the Reconfigure message. In
addition,
the key is transmitted in plaintext to the client in earlier exchanges.
[...]

> [LS]: If the Reply message is dropped and there is no other authenticated
DHCPv6 server, then the scenario is no authenticated DHCPv6 server. And
then the client's following behavior is:
If there are no authenticated DHCPv6 servers or existing servers failed
authentication, the client behavior is policy specific.  Depending on its
policy, it can choose to repeat the server discovery process after certain
delay or attempt to use an unsecured DHCPv6 server.

> [LS]: I agree with your proposed point. Looking forward to your proposed
text on this.

> [LS]: In the secure DHCPv6 deployment draft, we mainly consider two
different
scenario: stable client with strict security policy and roaming client with
loose
security policy.
For the stable clients, such as the desktop PC in enterprise network, they
are
pre-configured the trusted servers' certificates or the trusted CAs'
certificates
for server authentication.
For the roaming clients, such as the smart phones in coffee room, it is
difficult
to be pre-configured the trusted certificates for authentication.
What do you think of the scenario classification?

> [LS]: The certificate option "MUST" be contained, and the signature option
and timestamp option "SHOULD" be contained.
Have I got what you mean?

> [LS]: In the current version, we consider the scenario where the server
indicates a failure in authentication. If the message fails certificate
validation, the DHCPv6 server SHOULD reply with an AuthenticationFail
error status code to the client.
So, you suggest to define a new error status code: DecryptionFail error
status code. If the DHCPv6 server fails decryption, the DHCPv6 server
SHOULD reply with an DecryptionFail error status code to the client.
Could you please check whether my understanding is correct?

> [LS]: The original text covers the scenario where the timestamp check
fails. But the lack of timestamp and timestamp check failure are two
different scenario. So I don't understand why the new text now loses
its original sense. Looking forward to the further guidance.

> an RFC2119 keyword, either SHOULD NOT or MUST NOT.

[LS]: How about the following text；
If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a way that
the authentication mechanism defined in RFC3315 don't understand. So, the
Authentication option SHOULD NOT be used if Secure DHCPv6 is applied.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Fri, 29 Jan 2016 11:30:52 -0800

At Thu, 21 Jan 2016 23:27:03 +0800,

> Looking forward to your further guidance.

I'm still not sure if my point was made clear...so let me be more
specific: in the following message exchanges:

1. Information-request from client to server(s)
2. Reply to the Information-request from server(s) to client
3. Encryption-Query from client to server
4. Encryption-Response from server to client

did you mean the Reply message of exchange #2?

If so, do you at least agree that it makes almost no sense to include
the explicit separate signature in messages 3 and 4?

> generate the self-signed certificate for authentication.

Right, but this argument also holds even if we have TOFU...

> So, I think that

...so these don't explain why we should now remove the public key
option.  One obvious, though possibly relatively minor, drawback of
only having a certificate is that it will make the message size even
bigger when we actually only need the public key.

I'm not necessarily opposed to removing the public key option if we
cover all such discussions and reach consensus, but I don't think I've
seen it yet.

[...]
> the key is transmitted in plaintext to the client in earlier exchanges.

I'm not sure if my point was really taken, but I'm okay with removing
the text in question anyway.  I'd add "...and so this method is
vulnerable to active attacks" to the second sentence.

[...]
> > [LS]: I agree with your proposed point. Looking forward to your proposed

Okay, will do separately.

> What do you think of the scenario classification?

I basically just asked the definition of "stable".  From the above
text it seems to mean DHCP clients like desktop PCs, excluding laptops
and smart phones with a BYOD policy.  If so, I'd say "In enterprise
network, the security policy is strict and the clients are stable
terminals" is not a realistic statement.

> Have I got what you mean?

I'm afraid not.  I talked about option request options, but your
answer seems to talk about something else.  Let's be very specific:
according to the original draft text, the initial Information-request
message MUST contain an option request option whose codes fields
include:

1. code of certificate option
2. code of signature option
3. code of timestamp option

What I tried to say is that 2 and 3 are redundant, since requesting a
certificate option should imply a request of signature and timestamp
option (in this context I'm forgetting the other discussion of whether
we really need the signature option).

> Could you please check whether my understanding is correct?

Introducing a new error code is related but a minor point.  My
question was about what the client should do if it sees that code (or
whatever signal that indicates this kind of failure).
> its original sense. Looking forward to the further guidance.

Let me rephrase my question: consider the following two cases:

1. the client includes the timestamp option but server fails to
   validate it
2. the client doesn't include the timestamp option but server wanted
   to have it

my original question was whether TimestampFail is included in the
response from the server for both cases.  I assumed the answer was
yes.  Am I correct?  If I am, your latest text seemed to lose the
coverage for case 1 since it only talks about case 2: "If the server
rejects such a message without Timestamp option".  Is it clearer?

> Authentication option SHOULD NOT be used if Secure DHCPv6 is applied.

I'd probably want to suggest something slightly different, but I'd
like to first discuss whether we really need a signature option.
Depending on the result of it this point may become even more moot.
Note also that if we at least don't include the signature option in
encrypted message, the coexistence issue doesn't exist in this case in
the first place.

p.s. there's another bigger open issue I separated from the rest of
the discussions:
https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI

--
JINMEI, Tatuya