Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK)

[Stephen Farrell <[e-mail]>]

On 29/09/15 16:23, Brian Rosen wrote:
> Using the emergency use case as an example of where privacy concerns
> drive requirements is a bad idea.

Interesting sentence! I think it, and one I'd write nicely illustrate
the difference in perspectives. The one I'd write is:

Using the emergency use case to drive requirements with the result that
privacy concerns are de-prioritised is a bad idea.

> 
> In emergencies, it’s MUCH more important that a call goes through and
> you get the help you need than privacy is maintained.  Privacy is
> highly desirable, but not at the cost of call failure.  In fact in
> most countries, when you place an emergency call, there is a
> statutory explicit loss of privacy.  Any mechanism has to fail in
> such a way that the call goes through and the privacy is lost, not
> the call fails and privacy is maintained.  If you fail to establish
> TLS, you retry without it, for example.
> 
> It would be much better to focus on the normal language translation
> service, where there is no explicit loss of privacy.

I'd be happier if the emergency use-case was downplayed, yes. However,
I don't think I agree that emergency use-cases have more stringent
privacy requirements, aren't they the same? The possible problem is
not the different privacy requirements but that the focus on emergency
calling is likely to lead to (IMO) the wrong balance being reached
when trading off privacy and availability.

S.


> 
> Brian
> 
> 
>> On Sep 28, 2015, at 6:13 PM, Stephen Farrell
>> <[e-mail]> wrote:
>> 
>> 
>> Hiya,
>> 
>> (Answering this one as it may provide my best entry point in the 
>> thread...)
>> 
>> On 28/09/15 19:36, Gunnar Hellström wrote:
>>> Some modality needs can have privacy and security implications
>>> that make it important to not communicate them openly.
>> 
>> Yes, the possibility that emergency services could make it harder 
>> to do the above is my main concern. And even moreso because the
>> way in which the WG choose to annotate a call with language
>> information could well be copied for other annotations. The upshot
>> could be that the need to consider emergency calls results in there
>> being no effective way to provide confidentiality (in particular)
>> for these kinds of annotation.
>> 
>>> Some modality requirement combinations may indicate that you have
>>> a disability that may make it slightly easier to commit a crime
>>> to you.
>> 
>> I think that's another issue, but less of a deal for me. There's
>> also the related issue that one might in some places/cases be more 
>> discriminated  against the more (some of) one's language
>> preference(s) are more public. (I can envisage specific real cases
>> where a caller might be reluctant to reveal an ability to speak
>> language-X because they fear that would result in worse treatment
>> of the person, regardless of the treatment of the call.)
>> 
>>> 
>>> Therefore it adds to the other usual reasons to keep the SIP
>>> exchange privacy protected.
>> 
>> But isn't the reality that many SIP messages are not protected?
>> 
>> As to charter language, I'd be happy if the charter said that there
>> is a need to ensure that language, like other annotations of calls,
>> does need to be something one can, in practice, protect, including
>> at the very least hop-by-hop confidentiality, but with some form of
>> e2e confidentiality being highly desirable (maybe based on TOFU or
>> similar in cases where multiple calls may occur between the same
>> parties). I'm not fussed about how exactly that is stated so long
>> as the result is that the kind of can't-be-secured solution that
>> might be attractive for emergency calling is not considered by
>> itself sufficient.
>> 
>> Or, if my impression of VoIP is outdated and in fact securing this 
>> kind of data is now routinely done, then I would agree that there 
>> might not be a need for specific charter text. (In that case, some 
>> pointers to descriptions of networks where that is the case would 
>> be useful.)
>> 
>> Lastly, now that I'm thinking about it a bit more, it is not clear 
>> to me if the security and privacy requirements for the two
>> different applications are considered the same or not. Either way,
>> it could be good to be explicit about that in the charter too.
>> 
>> Hope that helps, S.
>> 
>> 
>>> 
>>> /Gunnar
>>> 
>>> ----------------------------------------- Gunnar Hellström 
>>> Omnitor [e-mail] [phone]
>>> 
>>> Den 2015-09-28 kl. 17:35, skrev Bernard Aboba:
>>>> Stephen --
>>>> 
>>>> I happen to share your concern about potential security and
>>>> privacy issues with emergency services architectures.  For
>>>> example, I have reviewed proposals for state NG911
>>>> architectures that may not function well if traffic is
>>>> encrypted (e.g. they specify network-based intrusion detection
>>>> systems that assume access to cleartext).
>>>> 
>>>> That said, it is not clear to me how language negotiation makes
>>>> that problem worse (or better).  Presumably the specifications
>>>> referred to in the Charter would be compatible with IETF
>>>> security standards (e.g. SIP over TLS, Secure WebSockets, SRTP,
>>>> DTLS/SRTP, etc.) so that an emergency call made using the SLIM
>>>> specifications could be secured.
>>>> 
>>>> Since SLIM is not chartered to focus on security and privacy
>>>> issues relating to emergency services (or email), I'm not sure
>>>> what more can be done within this Charter to address your
>>>> concern.
>>>> 
>>>> ========================================
>>>> 
>>>> 
>>>> [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06:
>>>> (with BLOCK)
>>>> 
>>>> "Stephen Farrell" <[e-mail] 
>>>> <mailto:[e-mail]
>>>> <mailto:[e-mail]>>> Thu, 17 September 2015
>>>> 13:54 UTCShow header 
>>>> <https://mailarchive.ietf.org/arch/search/?email_list=slim&qdr=y#
>>>> <https://mailarchive.ietf.org/arch/search/?email_list=slim&qdr=y#>>
>>>>
>>>>
>>>> 
Stephen Farrell has entered the following ballot position for
>>>> charter-ietf-slim-00-06: Block
>>>> 
>>>> 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.)
>>>> 
>>>> The document, along with other ballot positions, can be found
>>>> here: https://datatracker.ietf.org/doc/charter-ietf-slim/
>>>> 
>>>> ----------------------------------------------------------------------
>>>>
>>>> 
BLOCK:
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>> 
I wonder if the security and privacy considerations associated
>>>> with email and WebRTC are so totally different that it might
>>>> really be better to handle language separately for each.
>>>> 
>>>> I'm also a bit leery of emergency calls being used to justify 
>>>> handling language in a way that exposes privacy unnecessarily. 
>>>> (I don't mean that language preference is highly sensitive, as
>>>> it's usually not, but I think there is a meme where emergency 
>>>> services are used to justify doing all sorts of stuff without 
>>>> security, so the call is more likely to get through.)
>>>> 
>>>> The first bit was a comment I made back in July and I don't 
>>>> think I saw any response. (But I may have forgotten.)
>>>> 
>>>> We can chat about it on the call.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ SLIM mailing
>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/slim
>>> 
>>> 
>> 
>> _______________________________________________ SLIM mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/slim
> 
>