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

Randall Gellens <rg+ietf@randy.pensive.org> Thu, 11 January 2018 22:10 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 C27FD127342 for <slim@ietfa.amsl.com>; Thu, 11 Jan 2018 14:10:49 -0800 (PST)
X-Quarantine-ID: <MvN2e22jTRoy>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 MvN2e22jTRoy for <slim@ietfa.amsl.com>; Thu, 11 Jan 2018 14:10:47 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ABB1D120725 for <slim@ietf.org>; Thu, 11 Jan 2018 14:10:47 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 11 Jan 2018 14:11:21 -0800
Mime-Version: 1.0
Message-Id: <p06240607d67d9003ae35@[99.111.97.136]>
In-Reply-To: <14c38c8d-1dbd-79f2-6959-bbf00d196a62@alum.mit.edu>
References: <151552189475.2065.12973411169880140522.idtracker@ietfa.amsl.com> <p06240606d67acbc7af70@[99.111.97.136]> <6123cac0-a946-b26b-2b3b-68ff7b28874f@alum.mit.edu> <p06240604d67bede7af48@[99.111.97.136]> <14c38c8d-1dbd-79f2-6959-bbf00d196a62@alum.mit.edu>
X-Mailer: Eudora for Mac OS X
Date: Thu, 11 Jan 2018 14:10:44 -0800
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, slim@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/GZepjLavmTHhJdyOTLCMp5hRhtc>
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: Thu, 11 Jan 2018 22:10:50 -0000

At 3:52 PM -0500 1/11/18, Paul Kyzivat wrote:

>  On 1/10/18 11:27 AM, Randall Gellens wrote:
>>  At 11:01 AM -0500 1/10/18, Paul Kyzivat wrote:
>>
>>>   On 1/9/18 3:08 PM, Randall Gellens 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).
>>>
>>>   Is this a real concern? IIUC the processing of emergency calls 
>>> prioritizes completion of the call above everything else. Lack of 
>>> support for a requested language should never result in call 
>>> failure.
>>
>>  It's a concern for calls in general that an attacker who is able 
>> to modify the signaling can cause calls to fail.  The attacker 
>> could modify the Request-URI, causing the call to be routed to, 
>> e.g., a pothole reporting line instead of the police, or to a 
>> completely bogus destination, or modify the Contact-URI or any 
>> other crucial element.
>
>  But that is nothing unique to SLIM. In this respect it is the same 
> as any sip call.

I completely agree.  On the other hand, there's no harm in reminding 
readers that the risk exists and pointing to other RFCs that discuss 
use of TLS and IPSec.

The Security Considerations section, in response to Alissa's comment, 
was changed to:

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

Do you think it needs to be changed?

--Randall




>>  It's true that where emergency calls are concerned, normally the 
>> priority is for the call to complete no matter what.  A PSAP is 
>> highly unlikely to fail a call if there are no languages in 
>> common.  RFC 6881 mandates use of TLS or IPSec but also that a 
>> call proceeds even if TLS or IPSec fail.
>>
>>>>   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.
>>>>
>>>>
>>>
>>>   _______________________________________________
>>>   SLIM mailing list
>>>   SLIM@ietf.org
>>>   https://www.ietf.org/mailman/listinfo/slim
>>
>>
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Liberals are trusting and optimistic because
they believe other people are much like themselves.
Conservatives are hostile and fearful because they
believe the same thing.