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

[Randall Gellens <[e-mail]>]

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


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_