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

[Paul Kyzivat <[e-mail]>]

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.

	Thanks,
	Paul

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