[spring] Benjamin Kaduk's Block on charter-ietf-spring-01-01: (with BLOCK)

Benjamin Kaduk <kaduk@mit.edu> Thu, 05 July 2018 12:57 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: spring@ietf.org
Delivered-To: spring@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37670130E29; Thu, 5 Jul 2018 05:57:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: spring-chairs@ietf.org, spring@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153079545917.11265.16492788162863031098.idtracker@ietfa.amsl.com>
Date: Thu, 05 Jul 2018 05:57:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/r65pzWgyKMmEpVNBH8ObK0rLkSQ>
Subject: [spring] Benjamin Kaduk's Block on charter-ietf-spring-01-01: (with BLOCK)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.26
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 12:57:40 -0000

Benjamin Kaduk has entered the following ballot position for
charter-ietf-spring-01-01: Block

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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-spring/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

This proposed charter has minimal text on security concerns, asserting that
the scope is limited to a single trust domain and only applying a weak
requirement to "strive to identify and address" security considerations
brought up by its technologies.

The text concerning a single trust domain seems to implicitly assume that
there is thus no need for cryptographic assurance of the integrity and/or
authenticity of origin for route information, a position whose accuracy
remains unclear to me.

A commitment to "strive" to do something is hardly any commitment at all,
in that failing to do that thing remains consistent with the commitment.

Additionally, the current charter text includes some security-related
items, noting that "there are a number of serious security concerns with
source routing at the IP layer", committing to define the SRv6 header so
that blind attacks are never possible (and with options to provide
additional security in some networks), and committing to provide a security
analysis for each protocol being developed.  Has anything changed in the
intervening five years to render these items unnecessary?  I don't see any
justification for why these commitments are being abandoned.