Subject: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

From: 神明達哉 <[email-masked]>
Date: Tue, 1 Nov 2016 14:52:43 -0700

I have a couple of higher-level comments on draft-ietf-dhc-sedhcpv6-17.

1. I still disagree with the following restriction described in
 Section 5.4:

   For the privacy consideration, we have to give up the
   previous server selection feature.

 Especially now that rfc3315bis is going to deprecate the delayed
 authentication protocol and sedhcpv6 will become the only current
 candidate to provide security for DHCPv6, I believe it should cover
 all basic features of DHCPv6 including "the previous server selection
 feature".  There is at least one way to support this feature
 (although it's operationally restrictive): share the same
 private/public key pairs by multiple servers that may respond to the
 same Solicit.  As far as I can see there's nothing in this
 specification that prohibits this operation (unlike an earlier
 version of the spec, we don't include the server ID option in
 the Encrypted-Query message for a Solicit).  Also the following
 sentence in Section 10 seems to assume this operation:

   It should be noted that the selected certificate may
   correspond to multiple DHCPv6 servers.

2. Algorithm negotiation still doesn't make much sense to me.  I have
   many questions and concerns related to this point, but instead of
   raising each of these, I'd suggest one specific alternative to
   consider: have the client send a list of supported algorithms in
   the initial Information-Request, and let the server choose one set
   of them and keep using the same set.  This way we don't have to
   worry about an "algorithm not supported" error in the middle of a
   DHCPv6 session (as a corollary, we don't have to worry about how to
   return an encrypted reply when the client's preferred encryption
   algorithm isn't supported by the server).  An obvious downside of
   this is that it reveals some information of the client (the list of
   supported/preferred algorithms), but IMO this is acceptable.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Thu, 3 Nov 2016 16:36:46 +0800

>    correspond to multiple DHCPv6 servers.
[LS]: Agree to what you said. The current version does not prohibits
this operation. This sentence should be deleted.

>    supported/preferred algorithms), but IMO this is acceptable.
[LS]: In the current version, the server firstly sends a list of supported
algorithms through the Reply message. Then the client processes it
according to the following method:
"If the checks fails, the Reply message is dropped.  If the
hash algorithm field is zero, then it indicates that the hash
algorithm is fixed according to the corresponding signature
algorithm.  If all the algorithms are supported, then the client
selects one hash algorithm, signature algorithm and encryption
algorithm from the provided algorithms set.  And then the client also
uses the same algorithms in the return messages."
So it is not possible that the the server does not support the
acknowledged algorithms. So we also don't need to worry
about how to return an encrypted Reply when the client's
preferred encryption algorithm isn's supported by the server.
Could you please check whether my understanding correct?

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Thu, 3 Nov 2016 11:54:11 -0700

At Thu, 3 Nov 2016 16:36:46 +0800,

> according to the following method:
[...]
> preferred encryption algorithm isn's supported by the server.

One issue of this approach is that there's no way to recover from the
situation where the client doesn't support any of the server-supported
algorithms.  Also, the server will have to include certificates of all
the supported algorithms and signatures for all combinations of
supported hash and signature algorithms as it doesn't know which of
these works for the client.  This along with requiring the server
to always include mandatory algorithms will make this approach
workable, but it seemed to me to be unnecessarily wasteful and
complicated.  Hence my suggestion.

Besides, the current draft is not clear that the server needs to
include all certificates and all combinations of signatures.  It's
also awkward to mention the AlgorithmNotSupported status code if "it
is not possible that the the server does not support the acknowledged
algorithms".  So, whether or not my suggestion is adopted, the current
version of draft has a lot of readability and technical issues (and so
I think it's way far from being ready for a last call).  These are
actually what I'd raise once I get to the point to discuss the content
of the draft, but I wanted to address the higher level matters first.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Fri, 4 Nov 2016 19:35:18 +0800

2016-11-04 2:54 GMT+08:00 神明達哉 <[email-masked]>:

> algorithms.

[LS]: For this situation, the client can sent the mandatory algorithms set
to the server.

Also, the server will have to include certificates of all
> complicated.  Hence my suggestion.

[LS]: I don't think that the client/server need to contain all the
supported
algorithms. In default, all the servers and clients support the mandatory
encryption, signature, hash algorithms. So the client/server may just
need to contain the preferred algorithms and some of mandatory
algorithms. And Randy suggested us contain a list of algorithm, not
all the algorithm.

> of the draft, but I wanted to address the higher level matters first.
[LS]: Maybe this version has some issues. I have submitted the xml/txt
files.
Could you please review the new version and modify it? I think that
we can discussed all the issues and move forward it as soon as possible.
And we can improve our efficiency in this way. Thanks a lot.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Fri, 4 Nov 2016 08:04:26 -0700

At Fri, 4 Nov 2016 19:35:18 +0800,

> [LS]: For this situation, the client can sent the mandatory algorithms set

...as long as the server includes certificate(s) and signature
for/with the mandatory algorithms.  One problem of the current version
is that this is not clear from the text.  Another issue is that this
is (IMO) wasteful, as discussed below.

> need to contain the preferred algorithms and some of mandatory

I was probably not clear enough by "all the supported algorithms", but
this is actually what I meant: all the preferred algorithms, and I
thought it was wasteful.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 4 Nov 2016 10:09:53 -0700

> this is actually what I meant: all the preferred algorithms, and I

To be a bit more specific, consider the following case:

Assume the server supports the following algorithms
  For Encryption: EM, E1
  For Signature: AM, A1, A2
  For Hash: HM, H1, H2
  (where EM, AM, HM are the mandatory algorithms)

Also assume algorithms for Ex and Ay are all completely different and
we need different public keys (thus different certificates) for all of
them.  And also assume we can use any combinations of Az and Hw to
construct the Signature option.  And suppose the server most prefers
E1, A2, H2 because these are the strongest, but it cannot assume a
particular client supports this combination.

Now, for the currently described protocol to work, the server will
need to include the following in response to the initial
Information-Request:

- Certificate for the public key for EM
- Certificate for the public key for E1
- Certificate for the public key for AM
- Certificate for the public key for A1
- Certificate for the public key for A2
- Signature using AM and HM
- Signature using AM and H1
- Signature using AM and H2
- Signature using A1 and HM
- Signature using A1 and H1
- Signature using A1 and H2
- Signature using A2 and HM
- Signature using A2 and H1
- Signature using A2 and H2

This is the (unavoidable) waste I'm envisioning in the current
protocol (or am I misunderstanding it?).

On the other hand, if we let the client tell the server supported
algorithms in Information-Request, the client will only have to show a
list of supported algorithm IDs.  For example, if the client supports
EM, E1, AM, A1, and HM, the client will only have to send an ID of
these 4 algorithms (10 octets in total).  These are all supported by
the server, so the server will return a Reply containing:

- Certificate for the public key for E1
- Certificate for the public key for A1
- Signature using A1 and HM

which (we assume) is the most preferred combination for the server,
and it's guaranteed the client understands it.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Mon, 7 Nov 2016 15:00:22 +0800

Hi, Jinmei,

Thanks a lot for your detailed explanation. Agree to what you said. Will
modify it according to your comments.

Best Regards,
Lishan

---

From: Lishan Li <[email-masked]>
Date: Mon, 7 Nov 2016 16:29:45 +0800

Please see the question in line.

Best Regards,
Lishan

> - Signature using A1 and HM
[LS]: In this way, we have two public key: public key for E1, and public
key for A1.
Which one will be used for the future encryption process?

---

From: Lishan Li <[email-masked]>
Date: Mon, 7 Nov 2016 16:43:40 +0800

Dear Jinmei，

If the Information-request message indicates the algorithms, then we need
to make the following update:
1. The Information-request message contains the new define algorithm
option, which contains the EA-id List, HA-id List, SA-id List;
2. The Certificate option contains the EA-id field, not EA-id List. And
signature option contains the SA-id field and HA-id field, not SA-id List
and HA-id List.

Best Regards,
Lishan

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 07 Nov 2016 09:44:12 -0800

At Mon, 7 Nov 2016 16:29:45 +0800,

> Which one will be used for the future encryption process?

(Obviously) the former, but I guess your real question is how the
client can determine that.  If so, that's a good point...I wasn't
aware of the ambiguity at the time of my previous message.  I'm afraid
we need some more additional protocol stuff to resolve this, e.g., add
a new field for the certificate option to specify for which it's
supposed to be used: encryption, authentication, or both.

--
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 07 Nov 2016 09:56:05 -0800

At Mon, 7 Nov 2016 16:43:40 +0800,

> option, which contains the EA-id List, HA-id List, SA-id List;

Yes.

> signature option contains the SA-id field and HA-id field, not SA-id List

For the certificate, see my other message.  For the signature, yes.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Tue, 8 Nov 2016 22:02:21 +0800

> supposed to be used: encryption, authentication, or both.

[LS]: Another problem is that: whether all the certificates needed to be
verified for authentication? In general, if the certificate is verified and
then the public key can be used for encryption.
So I think one certificate is enough for authentication and encryption,
which is usually certificate for the public key for E1. There is no need
to contain the certificate for the public key for signature algorithm.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Tue, 8 Nov 2016 09:18:10 -0800

At Tue, 8 Nov 2016 22:02:21 +0800,

> to contain the certificate for the public key for signature algorithm.

It'll be possible (and probably quite common) to share the same
certificate (public key) for both encryption and signature.  For
example, if we use RSA for encryption and RSASSA, it's quite likely
that we can use the same public key.  But, unless we impose an
explicit relationship between these two algorithms as part of the
protocol specification we cannot always assume that, so the protocol
itself should be generic so that it will work even if encryption and
signature algorithms are totally independent.  That's why I stated the
above example: "add a new field for the certificate option to specify
for which it's supposed to be used: encryption, authentication, or
both."

Whether to impose such an "explicit relationship" is a different
question, btw.  I think that's certainly an option and can make the
spec simpler at the cost of making it less flexible, but that should
be discussed and described in the spec explicitly, instead of leaving
it as an implicit assumption.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Thu, 10 Nov 2016 00:48:53 +0800

> it as an implicit assumption.
[LS]: There are two types of certificate: one type is used for encryption
and authentication, which contains the public key for encryption algorithm;
another type is used for signature versification, which contains the public
key for signature algorithm. We can set one field for this. If the field is
zero, then it indicates the first type. If the field is 1, then it
indicates the
second type. Looking forward to your further guidance.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Nov 2016 09:33:10 -0800

At Thu, 10 Nov 2016 00:48:53 +0800,
Lishan Li <[email-masked]> wrote:

> second type.

There are THREE types of certificates:
- one type is used only for encryption, which contains the public key
  for the encryption algorithm
- another is used only for authentication, which contains the public
  key for the signature algorithm
- yet another is used both for encryption and authentication, which
  contains the public key for the encryption and signature algorithms.

So...

> We can set one field for this. If the field is
> second type.

...if this is a proposal of adding a new field to the certificate
option, yes, I think that's one way forward except that there are
three types.

Alternatively, we might add both an EA-id and SA-id fields to the
option:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_CERTIFICATE       |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            EA-id              |            SA-id              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                  Certificate List(variable length)            .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(I'm not sure if this has to be a list of certificates instead of one
certificate, but that's a different question).

And we can use a value of 0 for EA-id and SA-id to mean this
certificate is not supposed to be used for encryption and signature,
respectively.  (The combination of 0, 0 makes no sense so we should
probably prohibit the use of it explicitly).

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Mon, 14 Nov 2016 15:42:39 +0800

> probably prohibit the use of it explicitly).
[LS]: So, there is no need to define a new field. The EA-id and SA-id are
used to identify the certificate type.
And the certificate list field should be changed to certificate field. If
multiple
certificates are contained, then multiple certificate option is contained.

Best Regards,
Lishan

---

From: Lishan Li <[email-masked]>
Date: Tue, 15 Nov 2016 00:16:41 +0800

> certificates are contained, then multiple certificate option is contained.
[LS]: In this way, the certificate option and Signature option all contain
the SA-id field. And the content of the two SA-ids are same.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 14 Nov 2016 09:24:21 -0800

At Tue, 15 Nov 2016 00:16:41 +0800,

> > used to identify the certificate type.

If you use this approach, correct.  Note, however, that I'm not
necessarily pushing a particular approach at this time.  I'm just
showing various possible approaches for discussion.  You may want to
consider pros and cons of these approaches yourself.

> > certificates are contained, then multiple certificate option is contained.

Regarding this, I'm not sure.  Basically the choice of EA-id and SA-id
should be fixed (it should be the most preferred one for the server,
and it's known that the client supports it), so the question is
whether we want to make it possible to include multiple different
certificates for that combination of EA and SA.  That sounds to me
like an unlikely scenario in practice, although being flexible/generic
itself is not necessarily bad.

> the SA-id field. And the content of the two SA-ids are same.

Yes (otherwise the recipient should treat it as an error condition).

BTW this makes me notice one related issue: it doesn't seem to be
possible for a server to identify the private key to decrypt the
message contained in an Encrypted-message Option contained in the
Encrypted-Query message unless it tries all private keys it might be
used.

--
jinmei

---

From: Lishan Li <[email-masked]>
Date: Tue, 15 Nov 2016 15:27:46 +0800

> Encrypted-Query message unless it tries all private keys it might be
[LS]: The private key which is corresponding to the public key for
encryption
algorithm is used for decryption. After sending the Reply message, the
message
transaction-id is used as the identifier of the private key for decryption.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 15 Nov 2016 10:01:15 -0800

At Tue, 15 Nov 2016 15:27:46 +0800,

> transaction-id is used as the identifier of the private key for decryption.

Can you be more specific about this?  For example, assume the client
tries to send a Solicit message encrypting it with a server's public
key (and assume the server supports multiple algorithms and multiple
key pairs).  The encrypted solicit message that the server receives
would look like this:

msg-type: Encrypted-Query
transaction-id: some random number the client generates on building
  the Encrypted-Query (per Section 15.1 of RFC3315 or 16.1 of
  rfc3315bis-06).
options:
  Encrypted-message option:
    option-code: OPTION_ENCRYPTED_MSG
    option-len: set appropriately
    encrypted DHCPv6 message: opaque data to be decrypted

Do you mean the server can use the transaction-id included in the
Encrypted-Query message to identify the algorithm and the private key
to decrypt "encrypted DHCPv6 message"?  If so, specifically how?  As
noted above the transaction-id value is chosen by the client at the
time of generating this message and the server cannot know or
(easily) predict it in advance.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Wed, 16 Nov 2016 20:17:40 +0800

In the before, Bernie proposed the same question. And we made the following
consensus: The Encrypted-Query and Encrypted-Response message use the same
transaction-id with the before Information-request and Reply message.

>   the Encrypted-Query (per Section 15.1 of RFC3315 or 16.1 of
[LS]: So, in this sample, the transaction-id is not some random number, but
the same content with the transaction-id in Information-request and reply
message.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Wed, 16 Nov 2016 09:49:01 -0800

At Wed, 16 Nov 2016 20:17:40 +0800,

> transaction-id with the before Information-request and Reply message.

I'm not sure if I fully understand it, but if I understand it I
suspect it doesn't really solve this issue.  Two different clients can
happen to use the same transaction-id for the initial
Information-request and Reply (almost at the same time).  And yet it's
possible that the preference and/or support level of algorithms for
these clients are different and the server uses different algorithms
and different key pairs for these clients.

Now, these clients will then set the same transaction-id in the
subsequent Encrypted-Query message.  So the server can't determine
which previous client (and therefore, algorithm and key) it should
assume sent the message.

Besides, (if I understand it correctly) it's not really a
transaction-id at all anymore - the client will have to keep using the
same transaction-id for all subsequent encrypted-query messages.  In
effect, this now works as a "key ID" (but it's incomplete even in that
sense due to the possible conflicts with other clients as noted
above).  Then why not introduce that concept more explicitly?  Since
we are designing a new protocol we don't have to rely on a hack such
as overloading the existing field (such a trick might be necessary if
we need to provide, e.g., backward compatibility, but that's not the
case here).

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Nov 2016 21:37:23 +0000

FYI - I don't recall recommending that transaction-id stay consistent. I agree with Jinmei that this isn't unique (multiple clients may be using the same).

If you need a number, it may be better to have an explicit one.

- Bernie (from iPhone)

> On Nov 17, 2016, at 2:49 AM, 神明達哉 <[email-masked]> wrote:
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Lishan Li <[email-masked]>
Date: Thu, 17 Nov 2016 22:19:33 +0800

> we need to provide, e.g., backward compatibility, but that's not the
[LS]: I don't think it is a problem caused by secure DHCPv6. DHCPv6
also has this problem. If the two clients share one same transaction-id,
how the server distinguish two clients? And a new transaction-id is
generated for Encrypted-Query and Encrypted-Response message,
two clients may also generate the same transaction-id.

Whatever, in your suggested method, the transaction-id in the
Encrypted-Query and Encrypted-Response message is used
as Key ID. There are two problem:
1. How is the key id generated?
2. how the server knows the private key for decryption.
The server has to tries to use all the private key that may
be used. Does the server identify the key id in the Reply
message, and then the client set the transaction-id in the
Encrypted-Query message with the acknowledged key-id?

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Nov 2016 07:53:12 -0800

At Thu, 17 Nov 2016 22:19:33 +0800,

> two clients may also generate the same transaction-id.

There seems to be some fundamental confusion about transaction-id.  In
bare DHCPv6, the transaction-id is for each client to match a response
with the message it sent (distinguishing from other messages the
client might have sent in parallel).  So there's no problem even if
multiple clients use the same transaction ID at the same time.  This
is a new problem introduced in your proposal.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Fri, 18 Nov 2016 00:56:35 +0800

> is a new problem introduced in your proposal.
[LS]: Thanks a lot for your explanation.
Then, for the next step, the transaction-id of Encrypted-Query and
Encrypted-Response message works as identifier for the public key
of encryption and private key for decryption.
When receiving the first Encrypted-Query message, the server has
to try all the private keys that it might use.
Could you please check whether my understanding correct?

Thanks again,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Nov 2016 11:51:27 -0800

At Fri, 18 Nov 2016 00:56:35 +0800,

> Could you please check whether my understanding correct?

Hmm...I'm afraid I don't understand your understanding:-)

My understanding of where we are is that we now agree that as of
sedhcpv6-17 the server can't efficiently identify the private key to
decrypt a message in an Encrypted-Query message.

I can think of two possible next steps from here:
1. leave the inefficiency: let the server try all possible private
   keys until it can decrypt the message or conclude no key works.
2. introduce some kind of concept of "key ID" (or "key tag", in which
   case 100% uniqueness isn't required) and have the client include it
   in Encrypted-Query messages.

I personally prefer option #2, but in that case I don't like to
overload the existing transaction-id field for this purpose.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Sun, 20 Nov 2016 01:11:18 +0800

>    in Encrypted-Query messages.
[LS]: I don't know why in this case, 100% uniqueness isn't required.
Key id is used as the identifier of the private key, can the two private
key (two clients) uses the same key id?

> overload the existing transaction-id field for this purpose.
[LS]: The standard DHCPv6 message format contains the
transaction-id. If the transaction-id is not contained, then the
message is not DHCPv6 message. Transaction-id field's size
is very small.
In the before presentation, we have showed that Encrypted-Query
and Encrypted-Response messages are DHCPv6 messages.
And no one proposed any problem. And I also think that
there is no problem. If you insist on your opinion, please
states the caused problem and modify the draft. I don't
have any comment on this.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Tue, 22 Nov 2016 09:53:30 -0800

At Sun, 20 Nov 2016 01:11:18 +0800,

> key (two clients) uses the same key id?

Because it's basically for making the key identification more
efficient.  It's similar to the key tag field of DNS RRSIG RDATA
(see RFC4034 Section 3.1).

> have any comment on this.

I didn't propose removing transaction-id.  I just pointed out that
your proposal (if I understood it) made it something actually
different from transaction-id.  I don't know whether we need to have a
discussion why "naming something that is not a transaction ID a
transaction-id is a problem", but if we can simply go to a discussion
on what we should actually do, my suggestion is:

- Introduce a new DHCPv6 option named "encryption key tag option".
  Its value is calculated from public key data (it's essentially a
  fingerprint of a specific public key).
- Encryption Query messages MUST include the encryption key tag
  option.  The option data MUST be calculated for the public key that
  the client uses to encrypt the encapsulated DHCPv6 message.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Wed, 23 Nov 2016 16:28:54 +0800

>   the client uses to encrypt the encapsulated DHCPv6 message.
[LS]: I agreed. I have two questions:
1. How does the client calculate the key tag? Maybe the hash
function can be used for the calculation.
2. For the first received Encrypted-Query message, how does the
server identifies the corresponding private key through the acknowledged
key tag?
one way is that: The server tries all the possible private key
and record the relation of key tag and the corresponding private key.
Another method is that: The server calculates the key tags of all the
private key and then finds the corresponding private key.
Looking forward to your further guidance.

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Wed, 23 Nov 2016 11:39:27 -0800

At Wed, 23 Nov 2016 16:28:54 +0800,

> function can be used for the calculation.

Anything that would generate reasonably different values for different
keys (but it doesn't have to be guaranteed) is fine.  A simple
"checksum" like the RRSIG key tag would probably suffice; using a
commonly known modern hash is also fine.

> Looking forward to your further guidance.

IMO this can be left to implementations.  But I expect most server
implementations will calculate the tag value when it generates a key
pair and maintain it with the key pair.  Note that if the server
implementator and administrator don't care about the efficiency it
could even calculate the tag value for its all public keys and compare
it to the value specified in the "encryption key tag option".  Or it
could even skip using the key tag and try all possible keys.  It's
inefficient but will still work.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Fri, 25 Nov 2016 14:29:41 +0800

> commonly known modern hash is also fine.
[LS]: So it is mostly a implementation problem and don't need to specify
it. Because for the algorithm agility, we defines the algorithm negotiation
mechanism between the client and server. So I the key tag generation
algorithm may also need negotiation mechanism. And then, the generation
algorithm should also be defined in our document.
Looking forward to your guidance.

> inefficient but will still work.
[LS]: Thanks a lot for your explanation. So we don't need to specify
this implementation problem in our document.

Best Regards,
Lishan

---

From: Lishan Li <[email-masked]>
Date: Sat, 26 Nov 2016 02:38:16 +0800

Another problem is that: how the client identify which public/private key
pair is used for DHCPv6 configuration process when the client have multiple
key pairs. In most cases, the client communicate with only one DHCPv6
server. Then, the client only uses one public/private key pair for the
DHCPv6 configuration process. So there is no need to define the mechanism.
Could you please check whether my understanding correct?

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Mon, 28 Nov 2016 10:00:39 -0800

At Fri, 25 Nov 2016 14:29:41 +0800,
Lishan Li <[email-masked]> wrote:

> it.

We need to describe it as part of the protocol as it's necessary for
interoperability.  It's similar to the fact that the calculation of
the DNS RRSIG key tag is part of the protocol standard.

> Could you please check whether my understanding correct?

In this case we can normally use the transaction ID (unlike the case
where the server needs to identify the key pair to decrypt the
received data)...except for Reconfigure.  So, in the end we probably
need to include the key tag option in the Encryption-Response
message.  Hmm, this leads to another question: which encryption
message should we use, Encryption-Query or Encryption-Response, to
encrypt a Reconfigure message?

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Tue, 29 Nov 2016 23:19:55 +0800

> the DNS RRSIG key tag is part of the protocol standard.
[LS]: OK. So how about using the hash algorithm for the encryption
key tag calculation?
Maybe the server don't need to know the calculation method. For the
first Encrypted-Query message with the new encryption key tag, the
server tries all the possible private keys and record the relationship
between the key tag and the corresponding public/private key pair.
And the server does not need to calculate the key tag locally.

> encrypt a Reconfigure message?

[LS]: The Reconfigure message is sent from server to client. So sure,
it should be encrypted in Encrypted-Response message.

Firstly, I think there is no need to design such a mechanism for it.
The DHCPv6 server communicates with multiple DHCPv6 clients.
So there is need to define a mechanism to identify the used public/private
key pairs. However, the client always communicates with only one DHCPv6
server. For the whole DHCPv6 configuration process, only one public
key is informed of the server and the corresponding public key is used
for decryption.

Assume it is need to design a mechanism for this. There are three method:
1. Transaction id as the identifier: now work for Reconfigure message;
2. Encrypted-Response message contains key tag.
3. Server Identifier as the identifier.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 29 Nov 2016 08:23:53 -0800

At Tue, 29 Nov 2016 23:19:55 +0800,

> [LS]: OK. So how about using the hash algorithm for the encryption

Do you mean the hash algorithm used for the signature option?  If so,
it doesn't sound like a reliable choice since it can be different for
different clients.

> And the server does not need to calculate the key tag locally.

This doesn't sound like reliable for the same reason.  While this can
certainly be designed in multiple different ways, I don't see why we
might want to allow the server to skip calculating the tag value for
its public keys.  It's a one-time operation for each key pair if the
server has a volatile storage and can store the value there (which
would be quite likely for middle-to-large scale servers).  Even if it
needs to calculate the tag value on every startup (and keep it in
memory throughout its runtime) it should be quite lightweight.

[...]
> server.

Is this guaranteed by the protocol specification?  If so, could you
provide specific text of an RFC (3315? or 3315bis?) that specifies
this restriction?  I agree that it's the most common way of DHCP(v6)
operation, but unless it's explicitly stated in the protocol
specification I think it's dangerous to design other protocols based
on such an implicit assumption.  I'm okay with the assumption itself,
but if it's an explicit restriction of the base protocol I'd suggest
explaining the assumption explicitly.

> For the whole DHCPv6 configuration process, only one public

I'm not sure if I understand this, but transaction-ID doesn't work in
the case of Reconfigure.

> 2. Encrypted-Response message contains key tag.

Yes, this can be one option.  Perhaps we might say:

- An Encrypted-Response message that encrypts a Reconfigure message
  SHOULD include Encryption Key Tag Option
- Encrypted-Response message MAY include Encryption Key Tag Option
  for other cases
- The client can use the key tag option (if included) or transaction
  ID (if non-0) to identify the private key to decrypt the data in a
  received Encrypted-Response message.  In practice, it's more likely
  that the client has only one possible key pair so the choice should
  be obvious.

> 3. Server Identifier as the identifier.

This can also work, but in that case we should update the spec so
Encrypted-Response messages can include the server identifier option.
It also relies on the assumption that there is only one DHCPv6 session
between the client with one particular server or if there are multiple
parallel DHCPv6 sessions the same key pair is used for all sessions.
As noted above, I'd be cautious to rely on implicit assumptions, so if
we choose this option I'd like to make the assumption explicit.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Wed, 30 Nov 2016 17:55:00 +0800

> memory throughout its runtime) it should be quite lightweight.
[LS]: It is not a one-time operation for each key pair. For different
clients, the key tag calculation method is different. For the multiple
calculation method, I don' t think it is lightweight.

Assume that the calculation method is needed, which method do
you suggested?

> explaining the assumption explicitly.
[LS]: In the case that multiple servers share one common certificate,
the Encrypted-Query message may be sent to multiple DHCPv6
servers. But they are informed of the same public key. And the
client also uses the same one private key for decryption.
So we can add the statement that: During the DHCPv6 configuration
process, the client MUST only use one certificate to establish the
encrypted communicate with the DHCPv6 server.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 30 Nov 2016 07:34:36 -0800

At Wed, 30 Nov 2016 17:55:00 +0800,

> clients, the key tag calculation method is different. For the multiple

I don't understand this.  Why is it different for different clients?
Perhaps you somehow assumed I was talking about the use of signature
hash algorithm (which can be different for different clients)?  I
wasn't; I said it didn't sound like reliable, and pointed out that if
we fix the calculation method it's a one time operation and the
overhead wouldn't be a big issue.  Maybe "if we fix the calculation
method" condition wasn't clear enough.

> Assume that the calculation method is needed, which method do

I have no specific suggestion or preference.  Perhaps just use the
same algorithm as RRSIG key tag?

> > this restriction? [...]

This didn't answer my question.  Could you first answer the question?
If there's no such restriction in the base protocol, we cannot assume
it and can't assume it in designing sedhcpv6.

--
JINMEI, Tatuya