Re: [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 20:24 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0241126579; Tue, 9 Jan 2018 12:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=n9YiCtbV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Kgap3H9/
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 3HIftCubIV5J; Tue, 9 Jan 2018 12:24:28 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752E41205F0; Tue, 9 Jan 2018 12:24:28 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B174620A9C; Tue, 9 Jan 2018 15:24:27 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 09 Jan 2018 15:24:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=OBbScXmbkuZ0s6DHqxQ5ws01Wjp8JtH86tGU7XaiOXs=; b=n9YiCtbV cOmScCoG1KtVxi8CV1uYo0u0imGOcu1bF/TVDK+mquuCCOlYsBn4IWkXe3bZVYtL nla/ywB7sNlHNuukDOXuhtcAoBgCujSeAjOBcpypuWEFaPr3z5JNaUKM4utwIkYy XZL7X9FwZPKvSPW8L6PQj+xS8Z/qTaI3HTVncMyxIznbEdAta5fcCm2uy2ji1iLc +MsO6Kj2XosAMNEdNxHbFRNhTijzD6HaiDKdD5DEYSjIkPDoT0T7R+IDXYlKVjWQ 0IluJuPRpS91mIeRauJynytChZ8qZ18HYiO0GS/u6p97efaY5iqKmlorzB/8Bo4m sJTU5ru3/p0HZw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OBbScXmbkuZ0s6DHqxQ5ws01Wjp8J tH86tGU7XaiOXs=; b=Kgap3H9/6A2swgeos/G95y13VmgJG2omPu+C0MZ/7A/Jm zqoGvdf6YheCaZH9vz7MeNmMVFjJNv8h49IBJMxm3xprhAO3QXtarm6m1ZBm0WB/ qqM2LmcV9HGeEb6iKfNpWtcOSRM8Nhx4VL89k+lNamYTf4b5vQKE2aSOw/SlAzKD kWUtUhprFhpHfEMyrj8OdsZtXY1UdxmM9E4xQ3sF+stk7N4DsK88IJ+JkLGql7oY dkExpRuhrnN7tHE/HMwCqynxFF90jDKYN0EdwY8hwiDubeVpyOyzDSY31kBsmRHT DWCn9D172xwjNtN6RzfoM+WqFd4k+O7HkvenAKetw==
X-ME-Sender: <xms:-yRVWhT3wlQXhTxxSb0a6EE9AUJpsj2IHt3MTy_OwbqlsGqKcln25Q>
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C2DD7E351; Tue, 9 Jan 2018 15:24:25 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FB05D357-A54C-4FA1-85FC-9FDD3933F314"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <p06240606d67acbc7af70@[99.111.97.136]>
Date: Tue, 9 Jan 2018 15:24:24 -0500
Cc: IESG <iesg@ietf.org>, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com, slim@ietf.org
Message-Id: <C1F6F9B2-5D10-4D3D-9839-6438A2E7864F@cooperw.in>
References: <151552189475.2065.12973411169880140522.idtracker@ietfa.amsl.com> <p06240606d67acbc7af70@[99.111.97.136]>
To: Randall Gellens <rg+ietf@randy.pensive.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/XuHGkbuldxrUT9uESqO6bzuDrFo>
Subject: Re: [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
Precedence: list
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 20:24:30 -0000

> On Jan 9, 2018, at 3:08 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
> 
> Hi Alissa,
> 
> Good point.  I can reword the Security Considerations section to read:
> 
>    The Security Considerations of BCP 47 [RFC5646] apply here.  An
>    attacker with the ability to modify signaling could prevent a call
>    from succeeding by altering any of several crucial elements,
>    including the 'hlang-send' or 'hlang-recv' values.  RFC 5069
>    [RFC5069] discusses such threats.  Use of TLS or IPSec can protect
>    against such threats.  Emergency calls are of particular concern; RFC
>    6881 [RFC6881], which is specific to emergency calls, mandates use of
>    TLS or IPSec (in ED-57/SP-30).

Sounds good, thanks.
Alissa

> 
> 
> At 10:18 AM -0800 1/9/18, Alissa Cooper wrote:
> 
>> 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:
>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> == Section 7 ==
>> 
>> "In
>>    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.
> 
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> In my country, we believe (and rightly so) that mindless superstition
> and meaningless ritual are what separate us from the animals.
>                                            --'Latka Gravis' on _Taxi_