Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)
"Ben Campbell" <ben@nostrum.com> Thu, 13 April 2017 03:25 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577E71286B1; Wed, 12 Apr 2017 20:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XW-ldvCbdiTT; Wed, 12 Apr 2017 20:25:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E6F94124D37; Wed, 12 Apr 2017 20:25:34 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3D3PUgE096516 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Apr 2017 22:25:30 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
From: Ben Campbell <ben@nostrum.com>
To: Bernie Volz <volz@cisco.com>
Cc: The IESG <iesg@ietf.org>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "draft-ietf-dhc-relay-server-security@ietf.org" <draft-ietf-dhc-relay-server-security@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Date: Wed, 12 Apr 2017 22:25:30 -0500
Message-ID: <ACAB925E-1A10-4C88-8F10-36A6E664F1B8@nostrum.com>
In-Reply-To: <7ED92DCC-697F-4877-B6ED-F8076BE1E854@cisco.com>
References: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> <D4BF03B4-792A-42A9-BDE6-5FA203D4D7F7@cisco.com> <CB02997F-BAE5-4F0D-9BD9-43D5FD4ACDDB@nostrum.com> <7ED92DCC-697F-4877-B6ED-F8076BE1E854@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/VY24ECT5k_byMsm4FQR1JwOrZUQ>
Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)
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: Thu, 13 Apr 2017 03:25:36 -0000
On 12 Apr 2017, at 22:11, Bernie Volz (volz) wrote: > Hi: > > OK, I’ll use conditions. > >> Is ESP with null encryption allowed? > > No. That was what RFC3315 had but this document changes that. That would suggest that the "MUST be secure" assertion in paragraph 4 is redundant with other normative text, and could be restated without the capitalized MUST. Ben. > > RFC 3315: > > Mode Relay agents and servers use transport mode and > ESP. The information in DHCP messages is not > generally considered confidential, so > encryption > need not be used (i.e., NULL encryption can be > used). > > This new draft: > > Encryption and authentication algorithms > This document REQUIRES combined mode > algorithms for ESP authenticated > encryption, > ESP encryption algorithms, and ESP > authentication algorithms as per Sections > 2.1, 2.2, and 2.3 of [RFC7321] > respectively. > Encryption is required as relay agents may > forward unencrypted client messages as well > as include additional sensitive > information, > such as vendor-specific information (for > example, [CableLabs-DHCP]) and [RFC7839]. > > - Bernie > > On 4/12/17, 10:52 PM, "Ben Campbell" <ben@nostrum.com> wrote: > > On 12 Apr 2017, at 17:31, Bernie Volz (volz) wrote: > > > Hi: > > > > For: > > > > -3, third paragraph: "MUST exchange messages securely" > > "Securely" is too ambiguous for a MUST. What specific > protections > > are > > required? > > > > I believe this also was the 4th paragraph? > > Yes > > > I guess there are two choices here: > > 1. Drop “securely” as we are just specifying to use IPsec. > > 2. Replace “securely” with “encrypted and > authenticated”. > > Seems to be #1 might be better (as it should be unnecessary > given that > > is what this document is about). > > Is ESP with null encryption allowed? > > > > > > > -3, paragraph 4: > > The list starts with no context. A sentence or paragraph > > describing the > > purpose of the list would be helpful. > > > > RFC 3315 had before this list: > > Relay agents and servers that support secure relay agent to > server > > or > > relay agent to relay agent communication use IPsec under the > > following conditions: > > > > But I’m not sure “conditions” is the best word? Not sure > if > > there is a better word to use to describe these items? > > Rules? Configuration? (But I don't think "conditions" is awful) > > > > > Perhaps replacing the first sentence in that 4th paragraph with: > > > > Relay agents and servers MUST exchange messages using the > > IPsec mechanisms described in [RFC4301] with the conditions > > as follows: > > > > And, move the remaining text in that 4th paragraph to the end of > > section 4 as a separate paragraph. > > > > - Bernie > > > > On 4/12/17, 4:39 PM, "Ben Campbell" <ben@nostrum.com> wrote: > > > > Ben Campbell has entered the following ballot position for > > draft-ietf-dhc-relay-server-security-04: Yes > > > > When responding, please keep the subject line intact and > reply to > > all > > email addresses included in the To and CC lines. (Feel free > to cut > > this > > introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be > found > > here: > > > https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > I am balloting "Yes", but I share the curiosity about > whether > > people will > > really do this. > > > > -3, third paragraph: "MUST exchange messages securely" > > "Securely" is too ambiguous for a MUST. What specific > protections > > are > > required? > > > > -3, paragraph 4: > > The list starts with no context. A sentence or paragraph > > describing the > > purpose of the list would be helpful.
- [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-rela… Ben Campbell
- Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-… Bernie Volz (volz)
- Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-… Ben Campbell
- Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-… Bernie Volz (volz)
- Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-… Ben Campbell
- Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-… Bernie Volz (volz)