Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014
Sheng Jiang <jiangsheng@huawei.com> Mon, 10 November 2014 17:50 UTC
Return-Path: <jiangsheng@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B273D1A034F for <dhcwg@ietfa.amsl.com>; Mon, 10 Nov 2014 09:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level:
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3KqVmg5eFj8 for <dhcwg@ietfa.amsl.com>; Mon, 10 Nov 2014 09:50:06 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CE61A1A6C for <dhcwg@ietf.org>; Mon, 10 Nov 2014 09:46:49 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLM05097; Mon, 10 Nov 2014 17:46:47 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Nov 2014 17:46:40 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 11 Nov 2014 01:46:36 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014
Thread-Index: Ac/xaWYb7j/iiP3ISmCf+ekbUUcpTQLRM7YAABe3580=
Date: Mon, 10 Nov 2014 17:46:36 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF732AC@nkgeml512-mbx.china.huawei.com>
References: <489D13FBFA9B3E41812EA89F188F018E1B6F6882@xmb-rcd-x04.cisco.com>, <5460C950.1050404@gmail.com>
In-Reply-To: <5460C950.1050404@gmail.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.149.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/cp43OzkQIrscWry02SWTgCzkt2Y
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 10 Nov 2014 17:50:12 -0000
Hi, Tomek, Thanks so much for careful review and detailed comments. We will integrate them into the new version. Best regards, Sheng ________________________________________ From: dhcwg [dhcwg-bounces@ietf.org] on behalf of Tomek Mrugalski [tomasz.mrugalski@gmail.com] Sent: 10 November 2014 22:18 To: Bernie Volz (volz); dhcwg@ietf.org Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014 On 26/10/14 12:11, Bernie Volz (volz) wrote: > This message starts the (short) DHC working group last call to advance > "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-04, document as a Standards > Track (Proposed Standard) RFC. The authors believe that this version is > ready. We had a WGLC earlier (May 2014 for the -02 version) and there > were some comments, so this is primarily to assure that those comments > were addressed. > > Tomek is the assigned shepherd for this document. Apologies for taking it so long to get this review done. This is my shepherd's review of this draft. I did review -04 version of this draft and I support this work moving forward. I have quite a few comments, but they are easy to fix and rather editorial in nature. I rechecked my previous review comments (sent on May 30). Thank you for addressing them. The only unaddressed comment is about key and cert rollover. There's nothing to change in how the mechanism is working, but perhaps you could add a section about rollovers. For clients moving to a new certificate, it should be pretty easy - once the old one is about to expire, the client gets a new cert and starts using it. The server will verify the new signature and it will all work. Updating the server keys will be trickier. From the client's perspective, probably another leap of faith would be required. In fact, a server updating its keys would be indistinguishable from a new rogue server pretending to be the legitimate one. Anyway, this is something that should be discussed, but I don't think there's anything you need to do here protocol wise. The text in section 3 could be improved. It mentions that there are two key management mechanisms. The first is mentioned immediately ("Firstly,..."), but the second one is mentioned 3 paragraphs further down. How about this: For the hash key function, there are two key management mechanisms. The first one is a key management done out of band, usually through some manual process. The second approach is to use Public Key Infrastructure (PKI). As an example of the first approach, operators can set up a key database for both servers and clients which the client obtains a key before running DHCPv6. Manual key distribution runs counter to the goal of minimizing the configuration data needed at each host. The next paragraph mentions this: "[RFC3315] provides an additional mechanism for preventing off-network timing attacks using the Reconfigure message: the Reconfigure Key authentication method. However, this method provides no message integrity or source integrity check.". I disagree. It provides both, but the protection is very weak. Section 4, first line on page 5. CA is mentioned for the first time, but the name is explained. Please replace its first use with "Certificate Authority (CA)". Section 5.1: Please rename OPTION_PK_PARAMETER to OPTION_PUBLIC_KEY. It will be more intuitive. Section 5.2: Please rename OPTION_CERT_PARAMETER to OPTION_CERT. Section 5.3: "both signature and authentication option are presented" => "both signature and authentication option are present". Section 5.5 should include a brief introductory text. Maybe the following would be useful: "The following new status codes are defined. See Section 5.4 of RFC3315 for details.". Section 6.1 "The client MAY switch to other certificate if it has." => "The client MAY switch to other certificate if it has another one." The following two sentences contradict each other "But it SHOULD NOT retry with the same certificate. It MAY retry with the same certificate following normal retransmission routines defined in [RFC3315].". Better way to express the intention would be: "If client decides to retransmit using the same certificate after receiving AuthenticationFail, it MUST NOT retransmit immediately and MUST follow normal retransmission routines defined in RFC3315." Section 6.2 "multiple Signature option is presented" => "multiple Signature options are present". "If neither of the Signature, Public Key or Certificate options is presented,". I'm not 100% sure on this one, so I ask a native speaker to confirm it, but I think that neither means "not one or the other" and can be used only if there are exactly two alternatives. So it would be better to say: "If none of the Signature, Public Key or Certificate options is present," "A fast search index may be created for this list." This is an implementation detail and I'm not sure if it should be placed in the draft. But I won't insist if you want to keep it. "It restores public keys from all trustworthy senders." => "It stores public keys from all trustworthy senders." The text starting with "Furthermore, the node that supports the verification of the Secure DHCPv6 messages MAY record the following information:" mentions minbits explicitly, but maxbits implicitly. I think it would be easier to say something like "The node MAY impose additional constraints for the verification. For example, it may impose limits on minimum and maximum key lengths." Section 6.4: "After the signature verification also successes" => "After the signature verification also succeeds" Section 6.4 does not mention that the timestamps must be strictly monotonously increasing. Right now, an attacker can capture a valid packet and then replay it rapidly as long as the inequality holds. Section 7. Your refer to the same feature as leap-of-faith, Leap of Faith and mention its abbreviated form (LoF) multiple times, yet almost never use LoF on its own. Please make this consistent throughout the document. Oh, and section 7.1 mentions "Leaf of Faith". "such as a network cafe" => "such as a network in a cafeteria". Section 8 - I think it would be a good place for a discussion about key/certs rollovers. See my comments at the beginning of this mail. Sedhcpv6 deployment has privacy implications. You should discuss them, even if very briefly. I'm not sure what's the best way to express it. Maybe saying something that secure clients should not expect any privacy as they reveal additional information in their certs? That's not a bad thing, it's just client privacy and client authentication are in practice mutually exclusive. Section 9 "This document defines three new ..." => "This document defines four new ..." (also three => four) further down the same paragraph. Section 10 "IETF DHC working groups". There's only one DHC WG :) Please replace reference to 5996 with 7296. Ok, that's it. Even though the number of corrections is significant, they are all editorial in nature. I strongly support this document moving forward. Thank you for doing this work. I find it highly useful. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Res… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Templin, Fred L
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Templin, Fred L
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Templin, Fred L
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Templin, Fred L
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Templin, Fred L
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Templin, Fred L
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Templin, Fred L
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Francis Dupont
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Francis Dupont
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Francis Dupont
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Francis Dupont
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Tomek Mrugalski
- [dhcwg] WGLC summary on draft-ietf-dhc-sedhcpv6-0… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 -… Sheng Jiang
- Re: [dhcwg] WGLC summary on draft-ietf-dhc-sedhcp… Sheng Jiang