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

From: Alissa Cooper <[email-masked]>
Date: Tue, 09 Jan 2018 10:18:14 -0800

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.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jan 2018 12:08:05 -0800

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

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

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 9 Jan 2018 15:24:24 -0500

> On Jan 9, 2018, at 3:08 PM, Randall Gellens <[email-masked]> wrote:
> 
> Hi Alissa,
> 

Sounds good, thanks.
Alissa

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jan 2018 11:01:06 -0500

>     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

>>  Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Jan 2018 08:27:08 -0800

> support for a requested language should never result in call 

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

>  _______________________________________________
>  SLIM mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/slim

-------------- Randomly selected tag: ---------------
Intelligence is like underwear, everyone should have it,
but we shouldn't show it off.             --Gene Petret

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jan 2018 15:52:57 -0500

On 1/10/18 11:27 AM, Randall Gellens wrote:
> 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.

	Thanks,
	Paul

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Jan 2018 14:10:44 -0800

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

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

Do you think it needs to be changed?

--Randall

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

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