[dhcwg] Remaining Issue for Secure DHCPv6 WGLC

Lishan Li <lilishan48@gmail.com> Fri, 21 April 2017 08:45 UTC

Return-Path: <lilishan48@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4C1241294F4 for <dhcwg@ietfa.amsl.com>; Fri, 21 Apr 2017 01:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JO12KfISdhev for <dhcwg@ietfa.amsl.com>; Fri, 21 Apr 2017 01:45:11 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D7512948E for <dhcwg@ietf.org>; Fri, 21 Apr 2017 01:45:11 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id d80so1911769qke.3 for <dhcwg@ietf.org>; Fri, 21 Apr 2017 01:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JgkuBfaEVnRyJAglDZMAj3LInJpZMg08QcdJvgCL56Q=; b=aUa65ThgXJoUjrXjsW4W7tqRKvko66KhrOo8AXJdGPDbehzx6IzrMeCHORFCf8sbm+ KlWOewJDod9fAE4+SojcKUoQ7EcDYLOXJyR0fUK5aJ81E3HzZjYvKl7EHKYSGgeY+Rjj ZrxqwEqKX4NwyasACFVFZ8FDYnPolXOp/eYsQV45njP/sRqhWh1nV6SIKOdjce+Lxknp qlYLmUewE6kcIJYxFOHEP+oE74ou6aB6YQV/1t5UUzx1o5EEO5Ib1YfyTb1wehEMNBFL YJO+7ApRvtzURuX5x2q9xrSGI5ffrSWrmOunJKNvTOV68HoYqerC4nruhjz48HmOYuxD NTkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JgkuBfaEVnRyJAglDZMAj3LInJpZMg08QcdJvgCL56Q=; b=n61aG7Jj1Z1e47cdKJxtyBJkenygTT+9hASe3n3csauvn14MTmyZ+6wqOMWgeHN9mN W1pcPLzQ6S+cFbnkTeT03DvMuxZYgGqy4r0tqudtuZmz0pNs0uBQDXhO39eQz+LwicuP HmHQYYOVe4cupaAIJOnQaVFLJDUsS85nzN2Dac+8Av3DLb251mq215/K1gGVaK7i5Qe8 3/1sXD3b1uqRQWvJp9jhabiGtvtSAdpfpRuW2zp4HB4EczFtgi87DscyBEXpdXw4qczD zjc7ve4EyTn4WG8qNC19VliTF3lG7GO/eHzWMr2vIWMhZmyaM2gsheJGrl5ZjR4XGwSq hadQ==
X-Gm-Message-State: AN3rC/65Fm2i/shQ3l2D0lLAfyiwHM+qOh9dS67Cr2w2XzWTbUX/T0F5 O/9576ksx5qUA1UiTJDvBPDrOcztCg==
X-Received: by with SMTP id d7mr12650217qke.320.1492764310699; Fri, 21 Apr 2017 01:45:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Apr 2017 01:45:10 -0700 (PDT)
From: Lishan Li <lilishan48@gmail.com>
Date: Fri, 21 Apr 2017 16:45:10 +0800
Message-ID: <CAJ3w4Nd1j4SBYh3KebFYjRaCS3k1ux28mHPk7yvtTCkEjm7QUA@mail.gmail.com>
To: dhcwg <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c06016a790898054da94632
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Da6bcXv2gQ7W9AEdNR5TzpAI644>
Subject: [dhcwg] Remaining Issue for Secure DHCPv6 WGLC
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 08:45:13 -0000

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
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
transaction ID of 0 for Encryption-query messages (the client must
the ID when its implementation generates 0).  Otherwise it's possible for
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
It is not expected to be used by all DHCP implementations is every
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
to be used by all DHCP implementations in every deployment, just those who
interested in improved privacy. So maybe it should be called Security
Profile for
DHCPv6? I think this approach does not change anything from technical
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
everywhere. It's just a suggestion to consider, I don't insist on it if
authors or the WG

[LS]: Kathleen Moriarty also proposes this problem. She suggested us to
have opportunistic security as mandatory to implement. Otherwise, the
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
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
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
would accomplish this if we are using more than just the encryptedContent?
something to think about.

[LS]: According to Sten Carlsen's comments, there is no other method than
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.
can you always detect that the decryption was a success or failure? Some
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
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,