[Slim] Alissa Cooper's No Objection on draft-ietf-slim-negotiating-human-language-22: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Tue, 09 January 2018 18:18 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: slim@ietf.org
Delivered-To: slim@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B980B124207; Tue, 9 Jan 2018 10:18:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com, slim@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151552189475.2065.12973411169880140522.idtracker@ietfa.amsl.com>
Date: Tue, 09 Jan 2018 10:18:14 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/jGiWB2g0kpB5hFFz5gSayP9iHq4>
Subject: [Slim] Alissa Cooper's No Objection on draft-ietf-slim-negotiating-human-language-22: (with COMMENT)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jan 2018 18:18:14 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-slim-negotiating-human-language-22: No Objection

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:


== Section 7 ==

   addition, if the 'hlang-send' or 'hlang-recv' values are altered or
   deleted en route, the session could fail or languages
   incomprehensible to the caller could be selected; however, this is
   also a risk if any SDP parameters are modified en route."

Given that one of the primary use cases for the attributes defined here is for
emergency calling, it seems worthwhile to call out the new specific threat that
these attributes enable in that case, namely the targeted manipulation/forgery
of the language attributes for the purposes of denying emergency services to a
caller. This general class of attacks is contemplated in Section 5.2.2 of RFC
5069, although there may be a better reference to cite here for what to do if
you don't want your emergency calls subject to that kind of attack (I can't
recall another document off the top of my head).

== Section 8 ==

This seems weak for not including some words to indicate what to do to mitigate
the risks of exposing this information.