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

[Alissa Cooper <[e-mail]>]

> On Jan 9, 2018, at 3:08 PM, Randall Gellens <[e-mail]> 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_