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

From: Lishan Li <[email-masked]>
Date: Thu, 1 Dec 2016 19:46:06 +0800

2016-11-30 23:34 GMT+08:00 神明達哉 <[email-masked]>:

> At Wed, 30 Nov 2016 17:55:00 +0800,
> Lishan Li <[email-masked]> wrote:
>
> > > 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.
> > >
> > [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
>
> 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.
>
> > calculation method, I don' t think it is lightweight.
> >
> > Assume that the calculation method is needed, which method do
> > you suggested?
>
> I have no specific suggestion or preference.  Perhaps just use the
> same algorithm as RRSIG key tag?
>
[LS]: I have no idea to complete it. Please contribute the text about it.

>
> > > >
> > > > [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.
> > > [...]
> > > > key pairs. However, the client always communicates with only one
> DHCPv6
> > > > 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? [...]
> > >
> > [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.
>
> 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.
>
[LS]: I just think that it is a default fact. Could you please give an
example that the client communicates with two DHCPv6 servers
for the address configuration in the same time?

Best Regards,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Thu, 1 Dec 2016 11:44:29 -0800

At Thu, 1 Dec 2016 19:46:06 +0800,

> for the address configuration in the same time?

I don't have an example; I already noted it would be unlikely in
practice.  My point is that unless the restriction is specified in the
protocol we can't design a new protocol implicitly assuming that
restriction.  Otherwise someone may deploy the service with violating
the assumption, and we cannot blame them as it's invalid.  We should
either:
1. design the protocol (=sedhcpv6) so it can work without the
  assumption, or
2. explicitly state it's a restriction that this protocol assumes

BTW, on thinking about the reconfigure case more, I realized that
including a key tag option for the client public key in the Encrypted
Reply is probably a bad idea, as it could be used for client-tracking.
So, in the end, option #2 above may be the least bad option anyway.
The assumed restriction wouldn't be that restrictive in practice, and
the client can still try all possible key pairs (if it uses multiple
pairs) in the rare corner cases.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Fri, 2 Dec 2016 14:34:31 +0800

> pairs) in the rare corner cases.
[LS]: Agree. Then in this version, we adds the assumption description
clearly.

Best Regards,
Lishan

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Dec 2016 08:55:48 -0500

Can I ask, where are you guys on this?   There's been so much
discussion that I've lost the thread.   Is anybody producing a summary
of issues?

On Fri, Dec 2, 2016 at 1:34 AM, Lishan Li <[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Lishan Li <[email-masked]>
Date: Fri, 2 Dec 2016 23:53:03 +0800

Dear Ted, Jinmei,

Thanks a lot for your guidance and help to complete the draft. I have
summarized the discussion content. Looking forward to your further guidance.

1. Algorithm negotiation method
Before version:
Through the Reply message, the server informs the client of the encryption,
signature, hash algorithms list; And then the client selects one
encryption,
signature, hash algorithm from the algorithms list for the future
communication.

The disadvantage:
The Reply message contains the algorithms list. So, the Reply message
contains multiple certificate options, signature options. For different
encryption algorithms, the certificate is different. And for the different
hash and signature algorithms, the signature is also different.

So, we made the following update:
+-------------------+                           +--------------------+
|DHCPv6 Client|                            |DHCPv6 Server|
+-------------------+                           +--------------------+
      |            Information-request           |

      |-------------------------------------------->|
      |             Algorithm option               |
      |           Option Request option       |
      |                                                     |
      |                    Reply                        |
      |<-------------------------------------------|
      |             Certificate option              |
      |             Signature option               |
      |          Increasing-number option   |
      |         Server Identifier option         |

(1) Define a new option: Algorithm option which contains the encryption,
signature, hash algorithms list.
Firstly, the client informs the server of the algorithms lists, and then
the server selects the algorithms from the lists. In this way, just only
one certificate, signature is contained.
(2) Delete the AlgorithmNotSupported error status code;
The algorithm option must contain the mandatory algorithms, so there is
no case that the server does not support the informed algorithms.

2. For server: The Identifier of the private key for decryption
Before version:
The server may have multiple public/private key pairs for multiple clients.
The transaction ID is used as the identifier of the private key for
decryption.
Firstly, the server informs the client of the certificate in the Reply
message and record the relationship of the key pair and the transaction ID.

The disadvantage:
The Encrypted-Query and Encrypted-Response messages must use the same
transaction-id of the Information-request and Reply message. And the
multiple clients may be using the same transaction-id.

So, we made the following update:
Add the Encryption Key Tag option to identify the used public/private
key pair. The Encrypted-Query message contains the Encryption Key Tag
option. The Encryption Key Tag option is calculated by the public key,
as the fingerprint of the public key.
For the calculation method, Jinmei thinks that it should be defined in
our document. In this way, the server can first calculate all the
key tag of the key pair locally. And then the server compares the
received key tag with it to find the corresponding private key for
decryption. In this way, the calculation method is also needed to
complete.
And my opinion is that: For the first Encrypted-Query
message, the server can try all the possible private keys and then
establishes the relationship of the Key Tag and the key pair.

3. For client: The identifier of the private key for decryption
Before version: Not Define the identifier of the private key;

Lishan's option: The client only uses one public/private key pair
with the DHCPv6 server. So there is no need to define a new
identifier;
Jinmei's opinion: This is based on the fact that: The
client only communicates with only one DHCPv6 server for configuration.
And there is no such restriction in the base protocol(RFC 3315 and bis)

Update: Add the description that: During the DHCPv6 configuration process,
the client MUST only use one certificate to establish the encrypted
communicate with the DHCPv6 server.

4. error status code
Before version: 1. If the server receives the solicit message without
the certificate option, the server sends the encrypted UnspecFail
error status code to the client.
2. If the server receives the Encrypted-Query message and decryption
fails, then sends the encrypted DecryptionFail error status code to
the client.

Issue: For the above two cases, the server cannot know the public
key of the client, there is no way to send the encrypted Reply
message to the client.

Update: The server just drops the message without sending the
error status code to them.

Best Regards,
Lishan