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

From: Bernard Aboba <[email-masked]>
Date: Mon, 28 Sep 2015 08:35:40 -0700

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" <[email-masked]> Thu, 17 September 2015 13:54
UTCShow header
<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.

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 28 Sep 2015 20:36:51 +0200

Some modality needs can have privacy and security implications that make 
it important to not communicate them openly.
Some modality requirement combinations may indicate that you have a 
disability that may make it slightly easier to commit a crime to you.

Therefore it adds to the other usual reasons to keep the SIP exchange 
privacy protected.

/Gunnar

-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

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).
>
> 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.
>
> relating to emergency services (or email), I'm not sure what more can 
> be done within this Charter to address your concern.
>
> "Stephen Farrell" <[email-masked] 
> <mailto:[email-masked]>> Thu, 17 September 2015 13:54 
> UTCShow header 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-slim/
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 28 Sep 2015 11:57:19 -0700

Gunnar said:

"Therefore it adds to the other usual reasons to keep the SIP exchange
privacy protected."

[BA] Agreed.  What can/should the Charter say about this?

For example, I noticed that the ECRIT WG charter contains the following
sentence:

"This working group will address privacy and security concerns within its
documents."

Is that enough?

On Mon, Sep 28, 2015 at 11:36 AM, Gunnar Hellström <
[email-masked]> wrote:

> [email-masked]
> +46 708 204 288
>
> "Stephen Farrell" <[email-masked]> Thu, 17 September 2015
> 13:54 UTCShow header
> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/charter-ietf-slim/
>
> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Sep 2015 15:16:08 -0400

> "This working group will address privacy and security concerns within its

Personally, I think things such as that are entirely unnecessary:
every working group needs to do that in all their documents, and the
IESG won't approve anything that doesn't.

Barry

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Sep 2015 15:59:11 -0400

> disability that may make it slightly easier to commit a crime to you.

It's hard to argue with the above in the abstract (*some* modality 
combinations). But in practice it seems like there isn't much choice. If 
you need to communicate via video rather than audio, then it is hard to 
hide that from the person you are communicating with. (It is easier to 
hide that you are blind since audio is the more common mechanism and 
many sighted people don't use video.)

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 28 Sep 2015 23:00:03 +0200

Den 2015-09-28 kl. 21:59, skrev Paul Kyzivat:
> combinations). But in practice it seems like there isn't much choice. 
> If you need to communicate via video rather than audio, then it is 
> hard to hide that from the person you are communicating with. (It is 
> easier to hide that you are blind since audio is the more common 
> mechanism and many sighted people don't use video.)
Some hard-of-hearing users want to try to hide that fact by using a very 
rapid captioned telephony service. The indication of the needs could 
then stay between the user and the service.

It may also in many cases be OK to reveal your preferences to the other 
party, but not to eavesdroppers.

Deaf-blind users are among the ones who may want to hide the preferences 
to eavesdroppers because of higher crime risk.

/Gunnar

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Sep 2015 23:13:58 +0100

Hiya,

(Answering this one as it may provide my best entry point in the
thread...)

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

> 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

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Sep 2015 20:12:11 -0400

> then stay between the user and the service.

Are they successful in hiding it???

> party, but not to eavesdroppers.

Well, since many cases have a middle box acting on the preferences it is 
hard to hide the indication from the middle boxes.

> to eavesdroppers because of higher crime risk.

I don't see how to hide it from those who can see the signaling. 
Encrypting the signaling channel can help hide it from snoopers.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Sep 2015 08:08:15 -0700

Stephen Farrell said:

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

[BA] Everything in the SLIM charter could potentially be protectable either
via the transport (e.g. SIP over TLS) or in principle via the
(non-deployed) S/MIME mechanism.  However, at this point, I think it is
safe to say that deployment of S/MIME in SIP is probably a lost cause, so
referencing that in the Charter would represent the triumph of hope over
experience.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Sep 2015 11:23:35 -0400

Using the emergency use case as an example of where privacy concerns drive requirements 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.

Brian

> On Sep 28, 2015, at 6:13 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>>> <mailto:[email-masked] <mailto:[email-masked]>>> 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#>>
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Sep 2015 16:30:55 +0100

On 29/09/15 16:08, Bernard Aboba wrote:
> via the transport (e.g. SIP over TLS) 

Yes, but is that actually in common use now for SIP? And if it is could
STIR be used to get e2e authentication with hbh confid?

> or in principle via the

Fully agree - if the charter claimed e2e was needed I'd have a block
on that for wishful thinking.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Sep 2015 16:35:14 +0100

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

>>> Some modality needs can have privacy and security implications
>>> that make it important to not communicate them openly.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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 [email-masked] +46 708 204 288
>>> 
>>>> 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
>>>> 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.
>>>> 
>>>> <mailto:[email-masked]
>>>> <mailto:[email-masked]>>> 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#>>
>>>>
>>>>
>>>> 
>>>> 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.)
>>>> 
>>>> here: https://datatracker.ietf.org/doc/charter-ietf-slim/
>>>> 
>>>> with email and WebRTC are so totally different that it might
>>>> really be better to handle language separately for each.
>>>> 
>>>> (I don't mean that language preference is highly sensitive, as
>>>> it's usually not, but I think there is a meme where emergency 
>>>> _______________________________________________ SLIM mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/slim
>>> 
>>> 
>> 
>> _______________________________________________ SLIM mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/slim
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Sep 2015 11:55:21 -0400

> when trading off privacy and availability.
Usually, it works best to figure out what privacy is needed for the more normal cases.  Then you try to use the same mechanism for the emergency case, but you need a fall-back so the call goes through even if the designated mechanism fails.  Usually its something simple like retry without the security mechanism.  We’d like there to not be a bunch of mechanisms, any of which can fail and cause us to retry.  So, we’re already trying to use TLS and SRTP everywhere, and fail to normal TCP or even UDP with no SRTP if we can’t establish the call.  I wouldn’t want to see another mechanism used for this problem.  SIP uses TLS on the signaling to enforce privacy on the wire, and accepts the issue of hop-by-hop security.   I think we can rely on that mechanism to protect the information for SLIM, and we don’t need anything else for SLIM signaling over SIP.  If we tried to do something special for the SLIM signaling over SIP, something more end to end, I would have a problem. Actually, since we want to be able to do routing based on language, hop by hop security is pretty much a requirement.

Brian

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Sep 2015 10:01:21 -0700

Stephen said:

"Yes, but is that actually in common use now for SIP?"

[BA] In "legacy SIP", no - but for implementations that shipped this
decade, yes.  For example, today's SIP handsets and ATAs routinely support
SIP over TLS and SRTP (even handsets selling for less than $150).  In the
PBX space, both protected signaling and SRTP are widely supported
features.  For example, signaling and media security can be configured on
Asterisk and Skype for Business (SfB) uses SIP over TLS (and SRTP) by
default, including for SIP trunks and emergency calls.   In WebRTC,
signaling over a protected channel (HTTPS or WSS) is strongly encouraged
and widely used.  So signaling and media security is much more widely
supported today than it used to be.  If a recent deployment is not using it
(except perhaps for a secured SIP trunk provider which can be hard to find)
it is most likely because they don't care, rather than their equipment not
supporting it.

"And if it is could STIR be used to get e2e authentication with hbh confid?"

[BA] With STIR, yes.  AFAICT, there is nothing under consideration in SLIM
that would interfere with STIR.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 29 Sep 2015 16:24:03 -0400

I don't think Stephen is worried that emergency calls might go into
desperation mode and leak private information when that happens.  I
think he's worried that if we say <feature X> is used for emergency
calls, we might not address privacy issues adequately in the first
place, because emergency calling is that way.

That's a fair concern, but my answer to that is that emergency calling
is not the primary purpose of this work, and that security and privacy
issues will be raised and addressed, just as they would be in any
other working group -- I'm not convinced we need to say in every
charter that that will happen, and if we fall short on it (despite
being well aware of it and having at least one chair and a number of
participants who care), the IESG will call us on it.

I think it's something required of the documents to think about what
information needs to have its privacy protected and to give advice on
how to do it... and to include in that a warning that in emergency
call situations private information might leak (and stress that
leaking should be avoided to every extent possible).

I just don't think it makes sense to put it into the charter, any more
than putting a requirement for security considerations should be in
the charter.  It's just got to be a standard way we operate.

Stephen, if you think we really need something in the charter, please
suggest specific text and tell us where to stick it.[1]

Barry

[1] Ahem!  I didn't mean it THAT way.

On Tue, Sep 29, 2015 at 11:55 AM, Brian Rosen <[email-masked]> wrote:
> Usually, it works best to figure out what privacy is needed for the more
> normal cases.  Then you try to use the same mechanism for the emergency
> case, but you need a fall-back so the call goes through even if the
> designated mechanism fails.  Usually its something simple like retry without
> the security mechanism.  We’d like there to not be a bunch of mechanisms,
> any of which can fail and cause us to retry.  So, we’re already trying to
> use TLS and SRTP everywhere, and fail to normal TCP or even UDP with no SRTP
> if we can’t establish the call.  I wouldn’t want to see another mechanism
> used for this problem.  SIP uses TLS on the signaling to enforce privacy on
> the wire, and accepts the issue of hop-by-hop security.   I think we can
> rely on that mechanism to protect the information for SLIM, and we don’t
> need anything else for SLIM signaling over SIP.  If we tried to do something
> special for the SLIM signaling over SIP, something more end to end, I would
> have a problem. Actually, since we want to be able to do routing based on
> language, hop by hop security is pretty much a requirement.
>
> Brian
>
>
>
>
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 29 Sep 2015 22:50:38 +0200

I would think that RFC 7322 Section 4.8.5  RFC Style Guide has 
sufficient requirements for the security, referring to RFC 3552.
https://tools.ietf.org/html/rfc7322#section-4.8.5
So that we do not need to mention it specifically in the charter.

Gunnar

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Sep 2015 22:06:34 +0100

> place, because emergency calling is that way.

Yes, especially if feature-X is supported in a way that allows a
UA to annotate the call/mail with lots of other interesting
attributes for which the best we can do is hbh security.

> is not the primary purpose of this work, 

I'm not getting that impression. The charter calls out emergency calls
specifically as does draft-gellens-slim-negotiating-human-language.

> and that security and privacy

Hmm. It has been helpful a number of times to be able to say "well
your charter said you would do X but you have not done X." I'm not
sure we're yet at the point where we can just assume that WGs will
always do the right things for security and privacy. (I do think
we're getting better at that as it has increasingly real impact.)

> suggest specific text and tell us where to stick it.[1]

Heh. But sorry, no I'm not quite there yet.

Let me try this way. Annotating calls/mails with language is an instance
of annotating calls/mails with personal details of the sender/caller,
and some of those details could be very privacy sensitive (gender, age,
home address, politics). If SIP/SDP or MIME based approaches are taken
with language, nothing stops UAs adding many other kinds of information
into the same place(s) in our protocols. There could be commercial
benefits to some in including such information and users would not be
likely to understand the issues with this, just as they do not with
EXIF data in images to take one example.

Has someone done a general analysis of the security and privacy
consequences of adding that kind of information to calls/emails? If so,
great, and how does language fit in? If not, why is it ok to start with
language now without having done the general analysis? (I assume that
the slim WG would not plan to do such a general analysis.)

Cheers,
S.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Sep 2015 18:32:03 -0700

Stephen said:

"Has someone done a general analysis of the security and privacy
consequences of adding that kind of information to calls/emails? If so,
great, and how does language fit in?"

[BA]  The GEOPRIV WG undertook a security/privacy analyses with respect to
location acquisition in RFC 6280 and SIPCORE analyzed the security of SIP
location conveyance in RFC 6442.  As with language, this capability was not
solely for use in emergency calls.

These analyses apply beyond location. In particularly, the security
considerations relating to transport security in RFC 6442 apply quite
directly to SLIM.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Sep 2015 08:18:25 +0100

Hiya,

> solely for use in emergency calls.

Thanks. So yes, geopriv's analysis of the security and privacy
aspects of location conveyance should be a fine input here. But
there are differences, e.g. location can be inferred or checked
if one is 'nearby' (6442, 3.4) whereas language differs, I'm not
sure if the only thing that makes sense for language is "by value"
conveyance, etc.

> considerations relating to transport security in RFC 6442 apply quite

Yes again - 6442 section 7 seems to say reasonable things about
e2e security. However, it also says "In most cases, the UA has no
trust relationship with the proxy or proxies..." That gives me
pause, since one way to look at slim is that we're extending the
geopriv approach but now to handle attributes of the person and
not the UA. And it's not clear to me that we've considered the
trade-offs in making that kind of personal information available
to (what are to me as a user) random nodes on a path over which
I have essentially no control.

It's also not clear to me that slim, as planned, will really
consider those tradeoffs, as there is an implicit assumption in
the current charter that someone has done that and concluded that
exposing at least one such attribute (language) is, in the end,
worth doing. (Note: I am not here doubting the use-cases for
this, but I am doubting the analysis of the privacy implications
of meeting those use-cases.)

IOW, I just don't see that it as credible that slim is started
as a wg, that someone then does the privacy analysis and that
the wg then conclude that it's just a bad plan to even start
sending out such personal information this way and we then decide
to close the wg without developing standards for meeting these
use-cases. If the analysis has yet to be documented, and if
that sequence of events is not possible, then istm that this
charter does lack something.

One way to handle that might be to first require the proposed
wg to document the security and privacy properties of sending
this kind of information (not only language) and to require a
re-charter when that's done before developing the standards
track drafts that say how to convey language information. That
analysis should of course consider that we have no e2e security
in practice and hence anything done has to be reasonable when
there is only hbh security. I suspect that the analysis of the
calling vs. emailing use-cases here might also show up some
differences in the semantics/privacy aspects of language tags
when those are attached to the relevant PDUs. (In one case
the tag means "calls understands X" in the other it means "here
is where those who understand X find useful bytes.")

Now I'd be surprised if folks liked that idea, (as one way to
look at it is that I'm proposing bureaucratic nonsense;-) but
I am concerned that if we don't do such work, we're sliding yet
again down a privacy unfriendly slope for the usual good reasons
(emergency calls can benefit from this).

Cheers,
S.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Sep 2015 08:35:09 -0700

Stephen said:

"So yes, geopriv's analysis of the security and privacy
aspects of location conveyance should be a fine input here. But
there are differences"

[BA] Yes, language has very different properties than location.

However, some of the same considerations described in RFC 5606 could very
well apply here, since if language information needs to be accessible for
the purposes of routing, the information cannot be hidden from proxies.

So despite the elaborate privacy considerations of RFC 6280 and RFC 3693,
 RFC 5606 described the disconnects that arise:

   There is a use case for LI that involves embedding it in a SIP
   request that will potentially traverse multiple SIP intermediaries
   before arriving at a user agent server (UAS).  In this use case, one
   or more intermediaries might inspect the LI in order to make a SIP
   routing decision; we will hereafter refer to this as location-based
   routing.  Common examples could include emergency services and other
   more mundane cases where the originator of a SIP request wants to
   reach a service in proximity to a particular geographic location,
   such as contacting a nearby pizza shop.  In both such cases, the UAC
   may intend for selected intermediaries and the UAS to have access to
   the LI.  In the pizza case, for instance, the user agent client (UAC)

   shares an address both for location-based routing and additionally so
   that the pizza shop reached by that routing has the address to which
   a pizza should be sent.

   This location-based routing use case for LI has a number of important
   disconnects from the RFC 3693 <http://tools.ietf.org/html/rfc3693>
model.  Unlike the RFC 3693 <http://tools.ietf.org/html/rfc3693>
model,
   there is no LS designating to which specific entities LI will be
   sent.  There may be multiple intermediaries between the UAC and UAS,
   some of which will need or want to inspect LI (which would seem to
   qualify them as LRs) and some of them will not.  While SIP proxy
   servers generally are not [RFC4119
<http://tools.ietf.org/html/rfc4119>]-aware and do not need to inspect
   SIP request bodies in order to perform their function, nothing
   precludes proxy servers inspecting or logging any SIP message bodies,
   including LI.  Furthermore, it is very difficult for the UAC to
   anticipate which intermediaries and which eventual UAS a SIP request
   might reach.

   This architecture is further complicated by the possibility of
   sending location information by-reference, that is, placing a URL
   where LI can be retrieved in SIP requests instead of using a PIDF-LO
   body (commonly called including the PIDF-LO by value).  Depending on
   the qualities of a reference, further authorization checks may be
   performed before LI is retrieved, LI may be customized depending on
   who is asking, and so forth.  As will be discussed in greater detail
   below, the conveyance of a reference may have very different privacy
   properties than conveying a PIDF-LO body by-value in a SIP request.

   In this architecture, the question of who is an "authorized
   recipient" from the point of view of the Rule Maker has been muddy.

Stephen also said:

"One way to handle that might be to first require the proposed
wg to document the security and privacy properties of sending
this kind of information (not only language) and to require a
re-charter when that's done before developing the standards
track drafts that say how to convey language information."

[BA] The proposed sequencing of work items make it difficult to carry out
such a privacy/security analysis at the onset.

Since many of the security/privacy concerns arise from routing (as
described in RFC 5606), until those aspects are fleshed out, it would be
hard to understand the issues. For example, the privacy/security properties
of "by value"/"by reference" and SIP header/SDP routing are quite
different.

Stephen also said:

"Now I'd be surprised if folks liked that idea, (as one way to
look at it is that I'm proposing bureaucratic nonsense;-) but
I am concerned that if we don't do such work, we're sliding yet
again down a privacy unfriendly slope for the usual good reasons
(emergency calls can benefit from this)."

[BA] As demonstrated by RFC 5606, it is possible to do elaborate
privacy/security analyses at the onset, and then to realize much later that
the practicalities of service operations make it very difficult to apply
that carefully developed framework in practice.

However, we are older (and hopefully wiser) now, so it may be reasonable to
develop some kind of problem overview, describing some of the issues with
language negotiation, and tackling some basic questions and the
security/privacy considerations that might arise from them.  In other
words, we may have learned enough from RFC 5606 to understand some of the
potential privacy/security issues.

On Wed, Sep 30, 2015 at 12:18 AM, Stephen Farrell <[email-masked]

> >>>> use TLS and SRTP everywhere, and fail to normal TCP or even UDP with
> no
> >> SRTP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Sep 2015 12:00:22 -0400

At the end of the day there will be some tradeoffs between convenience 
and privacy that users will need to decide.

Configuring your device to provide your language in all calls could make 
for an improved user experience that many users may prefer. (E.g., not 
ever being asked to "press 1 for Spanish".) For many, that will outweigh 
the loss of privacy that may result.

It is probably important that users be given the choice. But that aspect 
is almost certainly outside the scope of this work.

	Thanks,
	Paul

On 9/30/15 11:35 AM, Bernard Aboba wrote:
> However, some of the same considerations described in RFC 5606 could
> very well apply here, since if language information needs to be
> accessible for the purposes of routing, the information cannot be hidden
> from proxies.
>
> So despite the elaborate privacy considerations of RFC 6280 and RFC
> 3693,  RFC 5606 described the disconnects that arise:
>
>
>     disconnects from theRFC 3693 <http://tools.ietf.org/html/rfc3693>  model.  Unlike theRFC 3693 <http://tools.ietf.org/html/rfc3693>  model,
>     servers generally are not [RFC4119 <http://tools.ietf.org/html/rfc4119>]-aware and do not need to inspect
> [BA] The proposed sequencing of work items make it difficult to carry
> out such a privacy/security analysis at the onset.
>
> hard to understand the issues. For example, the privacy/security
> properties of "by value"/"by reference" and SIP header/SDP routing are
> quite different.
>
> Stephen also said:
>
> privacy/security analyses at the onset, and then to realize much later
> that the practicalities of service operations make it very difficult to
> apply that carefully developed framework in practice.
>
> However, we are older (and hopefully wiser) now, so it may be reasonable
> to develop some kind of problem overview, describing some of the issues
> with language negotiation, and tackling some basic questions and the
> words, we may have learned enough from RFC 5606 to understand some of
> the potential privacy/security issues.
>
> On Wed, Sep 30, 2015 at 12:18 AM, Stephen Farrell
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Hiya,
>
>      > On Tue, Sep 29, 2015 at 2:06 PM, Stephen Farrell
>     <[email-masked] <mailto:[email-masked]>>
>      > wrote:
>      >
>      >>
>      >>> On Tue, Sep 29, 2015 at 11:55 AM, Brian Rosen
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>>>
>      >>>> designated mechanism fails.  Usually its something simple like
>     retry
>      >> without
>      >>>> any of which can fail and cause us to retry.  So, we’re
>     already trying
>      >> to
>      >>>> use TLS and SRTP everywhere, and fail to normal TCP or even
>     UDP with no
>      >> SRTP
>      >>>> special for the SLIM signaling over SIP, something more end to
>     end, I
>      >> would
>      >>>> have a problem. Actually, since we want to be able to do
>     routing based
>      >> on
>      >>>> [email-masked] <mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 30 Sep 2015 12:13:56 -0400

There are two aspects that need to be kept separate:
If we aren’t routing based on language, then only the endpoints need to know the information, and using hbh security exposes potentially private data.
If we are routing on language, then we need the language information available to the routing elements, and hbh security is exactly what is needed.

So we can observe that there are some privacy concerns when we aren’t routing, that intermediaries will see the language requests.  The sender is in control, and can decide whether the utility outweighs the risks.  

When we are routing, the risk is inherent in the system, and you either want the service or you don’t.

This only affects intermediaries in the path; the hbh security mechanisms keep the data private to observers.  We would have to note that observers may be able to see the route taken by a call and might be able to infer language preferences based on the route.

ALL of this is standard stuff for a security section, and none of it, IMO is has anything to do with charter.

Brian

> On Sep 30, 2015, at 12:00 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> At the end of the day there will be some tradeoffs between convenience and privacy that users will need to decide.
> 
> Configuring your device to provide your language in all calls could make for an improved user experience that many users may prefer. (E.g., not ever being asked to "press 1 for Spanish".) For many, that will outweigh the loss of privacy that may result.
> 
> It is probably important that users be given the choice. But that aspect is almost certainly outside the scope of this work.
> 
> 	Thanks,
> 	Paul
> 
>>    disconnects from theRFC 3693 <http://tools.ietf.org/html/rfc3693 <http://tools.ietf.org/html/rfc3693>>  model.  Unlike theRFC 3693 <http://tools.ietf.org/html/rfc3693 <http://tools.ietf.org/html/rfc3693>>  model,
>>    servers generally are not [RFC4119 <http://tools.ietf.org/html/rfc4119 <http://tools.ietf.org/html/rfc4119>>]-aware and do not need to inspect
>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>> 
>>    Hiya,
>> 
>>    <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>     > wrote:
>>     >
>>     >>
>>    <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>     >>>>
>>     >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>     >>>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
>>     >>>>
>>     >>
>>     >
>> 
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
>> 
> 
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Sep 2015 12:38:49 -0400

On 9/30/15 12:13 PM, Brian Rosen wrote:
> If we aren’t routing based on language, then only the endpoints need to
> know the information, and using hbh security exposes potentially private
> data.
> If we are routing on language, then we need the language information
> available to the routing elements, and hbh security is exactly what is
> needed.
>
> So we can observe that there are some privacy concerns when we aren’t
> routing, that intermediaries will see the language requests.  The sender
> is in control, and can decide whether the utility outweighs the risks.
>

This problem with this approach is that the UAC will, in general, not 
know whether the language is needed for routing or not.

OTOH, this depends a bit on what entity is considered to be the "end". 
AFAIK, language based routing will typically only be done after reaching 
a server that the caller would probably consider to represent the 
callee. (Routing beyond that point could be viewed as part of a 
decomposed UAS.) It would probably be sufficient if we had a way to 
secure the info prior to that point. (But I don't know a workable way to 
do that.)

	Thanks,
	Paul

> This only affects intermediaries in the path; the hbh security
> mechanisms keep the data private to observers.  We would have to note
> that observers may be able to see the route taken by a call and might be
> able to infer language preferences based on the route.
>
>> On Sep 30, 2015, at 12:00 PM, Paul Kyzivat <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Configuring your device to provide your language in all calls could
>> make for an improved user experience that many users may prefer.
>> (E.g., not ever being asked to "press 1 for Spanish".) For many, that
>> will outweigh the loss of privacy that may result.
>>
>> It is probably important that users be given the choice. But that
>> aspect is almost certainly outside the scope of this work.
>>
>> Thanks,
>> Paul
>>
>>>    disconnects from theRFC 3693 <http://tools.ietf.org/html/rfc3693>
>>>  model.  Unlike theRFC 3693 <http://tools.ietf.org/html/rfc3693>  model,
>>> <[email-masked]
>>> <mailto:[email-masked]><mailto:[email-masked]>>
>>> wrote:
>>>
>>>
>>>    Hiya,
>>>
>>>    <[email-masked]
>>> <mailto:[email-masked]><mailto:[email-masked]>>
>>>     > wrote:
>>>     >
>>>     >>
>>>     >> specifically as does
>>> draft-gellens-slim-negotiating-human-language.
>>>     >>
>>>    <[email-masked]
>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>     >>>>
>>>     >>>> need anything else for SLIM signaling over SIP.  If we tried
>>> to do
>>>     >> something
>>>     >>>>[email-masked] <mailto:[email-masked]><mailto:[email-masked]>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 30 Sep 2015 18:56:22 +0200

Is there anyone against the view that this discussion can take place 
when composing the security chapters, and does not influence the charter?

The discussion is good, and material can be collected for the security 
chapters.

Gunnar

Den 2015-09-30 kl. 18:38, skrev Paul Kyzivat:
> AFAIK, language based routing will typically only be done after 
> reaching a server that the caller would probably consider to represent 
> the callee. (Routing beyond that point could be viewed as part of a 
> secure the info prior to that point. (But I don't know a workable way 
> to do that.)
>
>     Thanks,
>     Paul
>
>>>>     >> I'm not getting that impression. The charter calls out 
>>>> emergency
>>>>    calls
>>>>     >> specifically as does
>>>>     >>> I think it's something required of the documents to think 
>>>> about
>>>>    what
>>>>     >> home address, politics). If SIP/SDP or MIME based approaches 
>>>> are
>>>>    taken
>>>>     >> consequences of adding that kind of information to 
>>>> calls/emails?
>>>>    If so,
>>>>     >> language now without having done the general analysis? (I 
>>>> assume
>>>>    that
>>>>     >>>> if we can’t establish the call.  I wouldn’t want to see 
>>>> another
>>>>     >> mechanism
>>>>     >>>> used for this problem.  SIP uses TLS on the signaling to 
>>>> enforce
>>>>     >> privacy on