[i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

"Ben Campbell" <ben@nostrum.com> Wed, 17 August 2016 21:11 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: i2rs@ietf.org
Delivered-To: i2rs@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 406C512D73A; Wed, 17 Aug 2016 14:11:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147146828725.23668.4809857469458650681.idtracker@ietfa.amsl.com>
Date: Wed, 17 Aug 2016 14:11:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/DaPkPRTVll6cnYC6QLCQN6YTP6M>
Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2016 21:11:27 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-07: Discuss

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:


In section 3.4, the text says that the requirements that the integrity
protection mechanisms can actually provide integrity protection are
SHOULD because some communication may occur over non-secure channels.
That does not follow, since the rationale is about use, while the actual
requirement is about capability.  As currently written, it leaves it
possible for people to select a protocol that cannot provide integrity
protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS.

In the third paragaph of 3.2, Isn't the point to say that ephemeral data
MUST be sent over a secure transport unless the data model explicitly
labels it as safe for insecure transports? As written, it seems to leave
room to send data that is not labeled as safe to also be sent over
insecure transports.


-2.1: I am on the fence about other's comments about copying definitions
here--but if you do copy them here, it seems strange to not mention
"client" or "agent".

I agree with Alissa about equating privacy and confidentiality.

I’m confused by the first paragraph. I don’t find strings of the form of
SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

It’s not clear to me how 5 and 6 differ. Is it just a matter of the
additional “before establishing a connection” part in 6?

-3.4: Isn't 15 simply a restatement of the third item under 14?

3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do
they simply recognize reality, or to they  grant permission?)