[dhcwg] Remaining Issue for Secure DHCPv6 WGLC

[Lishan Li <[e-mail]>]

Dear All,

Thanks a lot for all the valuable comments on secure DHCPv6 WGLC. As the
DHC chairs, Bernie and Tomek gave us many support and valuable comments.
It is my honor to work with them. Thanks to the DHC chairs.

For the proposed comments, there are still some remaining issues for
discussion
in the following.

1. Bernie: 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?

[LS]: According to Ted's comments, Clients that don't have the current time
don't get
very good security. I think that we can add it into the security
consideration part.

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

[LS]: Tomek has the same comment on the Reconfigure message. As Jinmei
suggested: If the encrypted DHCPv6 message is Reconfigure message, then
the transaction-id of the Encrypted-Response message is regenerated.

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

[LS]: Kathleen Moriarty also proposes this problem. She suggested us to
have opportunistic security as mandatory to implement. Otherwise, the
reader
will think that it's not pointing to a practical implementable RFC.
Maybe another way is Tomek's suggestion, changing the name of the draft.
In this way, there will be less issues.

4. Tomek: 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]: According to Sten Carlsen's comments, there is no other method than
careful
programming and careful testing with deliberate intent to find weak spots.
I think that it is a general problem for encryption, not the specific
problem for
secure DHCPv6.

5. Tomek: "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.

[LS]: I also think that it is a general security problem. Looking forward
to the guidance
from some security experts.

6. Bernie: Regarding the reference of RFC5652, check in with Stephen to
get more clarity on what pieces are applicable?

[LS]: Looking forward to the guidance from some security experts.

Looking forward to all the comments and guidance. Thanks in advance.

Best Regards,
Lishan