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

[神明達哉 <[e-mail]>]

At Wed, 16 Nov 2016 20:17:40 +0800,
Lishan Li <[e-mail]> wrote:

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

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