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

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Oct 2015 15:03:18 -0400

(It doesn't help that Stephen got removed from the CC list on this
part of the thread, and it might be best to put the IESG back onto it
also; I'm doing both here.)

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

Thanks, Gunnar; this is where my mind is on the point.  Stephen,
though, seems to have a position that this work shouldn't proceed
until a broader analysis is done.  I'm very much not convinced of
that, and I'd like more from Stephen on that point.

I think everyone agrees that whatever documents are produced by this
working group have to consider the privacy issues raised by language
labelling.  I don't think we need that explicitly called out in the
charter ("The working group must eat its vegetables."), but I'm happy
to have text in there if there's some specific text proposed.

What I think is not agreed upon is whether this work needs to be gated
on an overall privacy analysis of adding information (in general) to
SIP calls.

Let's please continue the discussion on that *with* Stephen and the
IESG in the loop.

Barry

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Oct 2015 00:35:09 -0700

Barry said:

"What I think is not agreed upon is whether this work needs to be gated
on an overall privacy analysis of adding information (in general) to
SIP calls."

[BA] Brian Rosen has made the point that (at a high level) we already know
what that security/privacy analysis is going to say, because including
language information in SDP or SIP headers does not change the fundamental
security properties of SIP.  So gating the work on that analysis is like
hoping that your next viewing of The Shining will have a more pleasant
ending.

The security facilities of SIP are well understood and their properties
have been analyzed before.  We have SIP over TLS, which is hbh,
 (undeployed) S/MIME, which can protect message bodies e2e, and RFC
4474bis.

We also more or less understand what a privacy analysis would say:  if the
user wants to provide information to enable better routing of their call
(e.g. language preference), this information cannot be kept secret from the
proxies that do the routing.

On Thu, Oct 1, 2015 at 12:03 PM, Barry Leiba <[email-masked]>
wrote:

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Oct 2015 09:46:24 +0100

Hiya,

> to have text in there if there's some specific text proposed.

I'm asking that the analysis be somewhat broader than only
considering language. (On the basis that if we define how to
add language then other personal attributes are likely to
be similarly handled in the relevant protocols, UAs and servers.)
If one did agree with that then I do think it ought be included
in the charter.

> on an overall privacy analysis of adding information (in general) to

Right, I get that the gating thing is iccky, and Bernard rightly
points out that even when we try do all that well, the end results
might not be so great, which is a totally fair point.

How about something like this:

"It is not unlikely that once there is a method for using language
as planned here, some implementations may similarly handle other
personal attributes. The wg will analyse the security and privacy
issues arising from having UAs emit language or other similar
attributes and then handle language attributes accordingly."

Not great wording, but I hope I'm getting clearer;-)

S.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 4 Oct 2015 17:19:12 -0400

> If one did agree with that then I do think it ought be included
...
> might not be so great, which is a totally fair point.

OK... given all that, I, at least, can support asking the working
group to do that kind of analysis, and including it in the charter.
I'm just one voice, so I'd like to hear from the people who will
actually do the work.  In any case, I'm certain that we will need
people from the Security Area to work on this in the working group, if
it's going to be of any real value, and I have to ask the Security ADs
to make sure we have that -- more than one person, I think, and people
who will take an active role.

> attributes and then handle language attributes accordingly."

How does this work, appended to the charter (at the end)?:

"Adding language information to the control streams will have security
and privacy implications that must be understood and documented, as
any protocol would have to do.  Beyond that, this may open the door to
inclusion of other information that could be more security- or
privacy-sensitive than language preferences, and it could be important
to have a close look at that early on.  Therefore, this working group
will include in its work a broader analysis of security and privacy
implications of including such information in this manner.  That
analysis may be written as a separate document, or may be included in
the working group's primary document(s).  The Security Area will
provide necessary ongoing participation for that analysis, and this
requirement will not block progress on the working group's main work
if such participation is not available."

Maybe wordier than it needs to be, but I'd like to be clear.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 4 Oct 2015 22:22:37 +0100

> Maybe wordier than it needs to be, but I'd like to be clear.

Yep, but I could go with that anyway. And I'll try get folks who'll
help. And I accept that there's a chance we won't succeed in getting
a useful or any analysis done.

Cheers,
S.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Oct 2015 19:57:08 -0700

>> How does this work, appended to the charter (at the end)?:

[BA] Support for language negotiation in SDP is not new. 

a=lang was first defined in RFC 2327, published in April 1998. 

Since then, this has been included in RFC 4566, published in July 2006, and will be included again in RFC 4566bis which is underway.

RFC 1766, published in July 1995, defines language tags based on ISO 639/3166. 

Given that language negotiation in SDP is 17+ years old, charter language that suggests it is a new problem, or ignores all the security considerations that have already been written (and all prior IESG reviews) strains credulity.