Subject: [Sipping] draft-ietf-sipping-profile-datasets and "Invisible"

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Mar 2008 15:33:39 -0800

$Id: draft-ietf-sipping-profile-datasets-00-rev.txt,v 1.1 2008/03/04 23:12:35 ekr Exp $

The "invisible" attribute in this spec strikes me as
ill-advised. The UA is under control of the client
and it's not the IETF's job to tell the implementor
that he can't show the user the settings on his
own device. In particular, this is basically
incompatible with open source clients.

-Ekr
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Wed, 5 Mar 2008 17:03:17 -0500

One of the reasons that prompted that was actually that the service
provider owns the device.  I don't believe the intent was to mandate
that a particular setting be tagged invisible, but to give the
implementer and the operator a way of obfuscating a feature or an
attribute that the operator owns and wants to hide from his subscribers.

-Sam 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Rescorla
Sent: Tuesday, March 04, 2008 6:34 PM
To: [email-masked]
Subject: [Sipping] draft-ietf-sipping-profile-datasets and "Invisible"

$Id: draft-ietf-sipping-profile-datasets-00-rev.txt,v 1.1 2008/03/04
23:12:35 ekr Exp $

The "invisible" attribute in this spec strikes me as ill-advised. The UA
is under control of the client and it's not the IETF's job to tell the
implementor that he can't show the user the settings on his own device.
In particular, this is basically incompatible with open source clients.

-Ekr
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Mar 2008 14:22:52 -0800

At Wed, 5 Mar 2008 17:03:17 -0500,
> attribute that the operator owns and wants to hide from his subscribers.

Yes, but there's no basically way to enforce this on the client
side, because the user controls the client (this is the DRM
problem). 

-Ekr

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 05 Mar 2008 17:54:12 -0500

Isn't this advice to the client?  Some clients will enforce this.  Some 
service providers will then deploy those clients that enforce this.  
There are plenty of clients today that do exactly this, that you 
purchase at retail for use with a particular service provider, who 
configures them with settings you don't get to see or change.  Shouldn't 
we be able to describe configuration data for those clients?

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Mar 2008 15:17:04 -0800

At Wed, 05 Mar 2008 17:54:12 -0500,
Josh Littlefield wrote:
> 
> Isn't this advice to the client? 

No, it's an RFC 2119 SHOULD NOT.

   o  hidden: Specifies that the user agent SHOULD NOT display the
      property value.  Display of the property value may be allowed
      using special administrative interfaces, but is not appropriate to
      the ordinary user.

> Some clients will enforce this.  Some 

Yes, but there's a huge difference from:

- The operator would prefer that you not display this value.

and 

- A conformant implementation SHOULD not display it.

The latter is basically incompatible with open systems, since the
user can simply choose a new client which will display it.

-Ekr

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Wed, 5 Mar 2008 23:48:10 -0500

RFC 2119 "SHOULD NOT" is not a 100% prohibition; it is synonymous with
"NOT RECOMMENDED".  So why should this be considered anything more than
advice to the client to weigh all circumstances before the implementer
goes against this recommendation??  As to non conformant implementations
there are plenty of non-conforming implementations of 3261 out there.
That should not prohibit the IETF from making a recommendation IMHO.

Sam

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2008 6:17 PM
To: Josh Littlefield
Cc: Eric Rescorla; Ganesan Sam-W00184; [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-profile-datasets and
"Invisible"

> Some clients will enforce this.  Some service providers will then 
> deploy those clients that enforce this.
> configures them with settings you don't get to see or change. 
> Shouldn't we be able to describe configuration data for those clients?

and 

The latter is basically incompatible with open systems, since the user
can simply choose a new client which will display it.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Mar 2008 10:27:03 -0800

At Wed, 5 Mar 2008 23:48:10 -0500,
Ganesan Sam-W00184 wrote:
> "NOT RECOMMENDED".

Yes, but there's no interoperability consideration here. The operator
just doesn't like it.

>  So why should this be considered anything more than
> goes against this recommendation?? 

I don't understnad why IETF should be endorsing that.

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Thu, 6 Mar 2008 22:45:01 -0600

> Yes, but there's no interoperability consideration here. The operator

It's worse than that. It's advice to the implementor to do something  
against the best interests of the user.

If we consider the Hippocratic oath "do no harm" a goal of protocol  
design, the requirement being discussed violates that goal.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Mar 2008 07:37:15 -0500

Dean,

While I actually think the configuration of a UA ought to be accessible 
to the user of the UA, I can see why not everyone thinks that way. Its a 
matter how you define "user".

As an analogy, consider a door knob. You might argue that door knobs 
should not have locks, because they simply make the knob less functional 
for the user of the knob - the one trying to open the door. But the lock 
is a good thing for the owner of the door, who doesn't want to allow use 
of the door by all potential users.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 7 Mar 2008 15:42:38 -0600

On Mar 7, 2008, at 6:37 AM, Paul Kyzivat wrote:

> Dean,
>
> While I actually think the configuration of a UA ought to be  
> accessible to the user of the UA, I can see why not everyone thinks  
> that way. Its a matter how you define "user".
>
> should not have locks, because they simply make the knob less  
> functional for the user of the knob - the one trying to open the  
> door. But the lock is a good thing for the owner of the door, who  
> doesn't want to allow use of the door by all potential users.

There certainly are use cases for locked-down systems, such as browser- 
only nodes sitting in public areas.

The IETF doesn't specify special behavior for these systems -- it is  
outside our scope. But we do avoid specifying "security through  
obscurity" mechanisms.

AFAIK, nowhere in any of the other IETF documents will you find  
examples of information that is returned by a server that carries the  
caveat "Please keep this secret from the user of the node receiving  
this information."

For example, can you imagine a DHCP option where the result is  
expected to be kept secret from the operator of the node receiving the  
DHCP response? There are computers out there that don't tell you some  
users what the computer's IP address currently is, but nowhere in the  
DHCP specification does it say that the IP address SHOULD not be  
revealed to the user or to any application that might reveal it to the  
user. If it was transmitted in plain text to a requesting application  
not running under a TPM, it's NOT a secret.

  You'll note we also don't do DRM specifications, and at some level,  
that;s the same conversation.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Mar 2008 11:22:30 -0500

I think the problem has been presented incompletely, which is leading to confusion.  I think what they're looking for is not to hide information from the owner/operator of the UA.  It would be pointless to expect such behavior anyway, as people have pointed out.  The topic at hand is more of a UA that is owned by someone other than the one using it - the "user" is not the owner.  For example, suppose you're the sysadmin of an enterprise in charge of desk-phones.  You want to provision information that only the administrator should have access to.  That semantic either has to be defined by an RFC, or you're tied to using one vendor's phones.

Or another example is configuring public kiosk UA's.  You want to let any John Doe walk up and use the UA, but not see certain details of the config.

Would it help if the draft put in wording to that effect?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dean Willis
> Sent: Friday, March 07, 2008 4:43 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Sipping] draft-ietf-sipping-profile-datasets and "Invisible"
>
>

---

From: Josh Littlefield <[email-masked]>
Date: Sat, 08 Mar 2008 15:05:46 -0500

I think this exactly captures the issue, and shows it's importance. Thanks.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 08 Mar 2008 18:34:00 -0500

At Sat, 8 Mar 2008 11:22:30 -0500,
Hadriel Kaplan wrote:
> 
> 
> I think the problem has been presented incompletely, which is
> leading to confusion.  I think what they're looking for is not to
> hide information from the owner/operator of the UA.  It would be
> pointless to expect such behavior anyway, as people have pointed
> out.  The topic at hand is more of a UA that is owned by someone
> other than the one using it - the "user" is not the owner.  For
> example, suppose you're the sysadmin of an enterprise in charge of
> desk-phones.  You want to provision information that only the
> administrator should have access to. 

Then the first thing you need is Trusted Computing to stop your
employees from substituting handsets of their own choice that
will display the data. Without that, this won't work.

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Mar 2008 21:53:41 -0500

> will display the data. Without that, this won't work.

I assume that what an enterprise admin would do is restrict the phones which can pull down config data, through some form of identification or shared secret at some layer.

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Mar 2008 11:46:14 +0000

Yes, indeed, enterprise are likely to restrict what devices can be
connected to their LAN. Even then, whilst a lot of information is
changeable only with administration rights, a lot of it is still visible
to the user. However, I have no objection to the "invisible" attribute
with the right wording around it.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 09 March 2008 02:54
> To: Eric Rescorla
> Cc: Paul Kyzivat; [email-masked]; Dean Willis
> I assume that what an enterprise admin would do is restrict 
> the phones which can pull down config data, through some form 
> of identification or shared secret at some layer.
> 
> -hadriel

---

From: [email-masked]
Date: Mon, 10 Mar 2008 12:42:03 -0500

From: Hadriel Kaplan <[email-masked]>

   administrator should have access to.  That semantic either has to
   be defined by an RFC, or you're tied to using one vendor's phones.

So far, so good.  But what prevents my cellular carrier from declaring
itself as the "owner" of my handset, and keeping me from getting
access to the phone's provisioning information?

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 Mar 2008 18:14:49 -0400

On Mar 8, 2008, at 11:22 AM, Hadriel Kaplan wrote:

> administrator should have access to.  That semantic either has to be  
> defined by an RFC, or you're tied to using one vendor's phones.
>
> Or another example is configuring public kiosk UA's.  You want to  
> let any John Doe walk up and use the UA, but not see certain details  
> of the config.
>

My initial thought is "no". The HTTP specifications from IETF do not  
explain how to lock down the browser's settings, which may also be  
needed on a kiosk system. It's just outside of a protocol  
specification's scope.

--
Dean

---

From: Josh Littlefield <[email-masked]>
Date: Mon, 10 Mar 2008 19:16:54 -0400

> needed on a kiosk system. It's just outside of a protocol  

I don't think that is an appropriate analogy, since HTTP is not about 
configuring browsers, whereas this dataset is about configuring UAs.

That said, I can see both sides of this.  For the SP who wants 
flexibility in controlling the visibility of settings on devices he 
controls, there is value in this.  There is one over-the-top SIP SP I 
can think of that uses a feature exactly like this now in a proprietary 
configuration file schema, but it is vendor-defined, and thus different 
for every device that SP supports.  It may be security through obscurity 
driving this (some of the hidden information is password data), or it 
may be a desire to provide a particular user experience that doesn't 
confront grandma with 5000 obscure settings.

On the flip side, for the owner of an "unlocked" device which may find 
when he configures it for service by an SP it becomes somewhat "locked 
down" without his knowledge, there is real potential for abuse.

So maybe what we need is to find a way for consenting vendors and 
service providers in enterprise or non-retail SP scenarios to both use 
the standard dataset and layer on visibility somehow.  We certainly 
don't *have* to describe a standard for doing that, as they can just do 
it easily enough in a proprietary way (such as a vendor-specific schema 
which uses XPATH to describe parts of the config data which should not 
be visible--probably describing user access control restrictions at the 
same time, or through an extension of the base schema to add these 
parameters).  But if we do specify a standard for doing it, then vendors 
and SPs who want to offer this support can do so without unique 
approaches for every different device.

If it's going to happen (and I believe it will), I'd rather it was 
well-defined than proprietary and obscure.

-josh

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Mon, 10 Mar 2008 19:31:59 -0400

Here is a suggestion based on an off line with Cullen...  Tongue not
quite firmly in cheek

Can we do a Hint xml element with sub elements of hidden...

"Hello you device... Would you please not display this... please please
pretty please"  

The user agent is completely at liberty to thumb its nose at you and
blow you a strawberry....

Sam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Josh Littlefield
Sent: Monday, March 10, 2008 7:17 PM
To: Dean Willis
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-profile-datasets and
"Invisible"

Dean Willis wrote:
>> I think the problem has been presented incompletely, which is leading

>> to confusion.  I think what they're looking for is not to hide 
>> information from the owner/operator of the UA.  It would be pointless

>> to expect such behavior anyway, as people have pointed out.  The 
>> topic at hand is more of a UA that is owned by someone other than the

>> one using it - the "user" is not the owner.  For example, suppose 
>> you're the sysadmin of an enterprise in charge of desk-phones.  You 
>> want to provision information that only the administrator should have

>> access to.  That semantic either has to be defined by an RFC, or 
>> you're tied to using one vendor's phones.
>>
>> Or another example is configuring public kiosk UA's.  You want to let

>> any John Doe walk up and use the UA, but not see certain details of 
>> the config.
>>

-josh

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Mar 2008 02:30:50 -0400

How about a slightly cleaner approach: define config XML attributes for the font used for displaying info on the client.  Then simply set font size=0 for the invisible ones.  ;)
-hadriel

> Of Ganesan Sam-W00184
> Sent: Monday, March 10, 2008 7:32 PM
> To: Josh Littlefield; Dean Willis

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Mar 2008 18:35:34 -0400

On Mar 11, 2008, at 2:30 AM, Hadriel Kaplan wrote:

> How about a slightly cleaner approach: define config XML attributes  
> for the font used for displaying info on the client.  Then simply  
> set font size=0 for the invisible ones.  ;)

Screen readers used by people who can't or prefer not to use visual  
recognition read 0-point fonts out loud. This has embarrassed a number  
of web developers.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Mar 2008 22:41:22 +0000

I think there are two concepts here:

1) Items that are under administrative control. This is a common
requirement in enterprises, for example, where the administration
requires control over configurable items to do with how the device
interacts with the network, codecs to be used, security policy, etc.. An
item under administrative control does not necessarily need to be
invisible to the user, but it must not be changed by a user without
administrative privileges. For example, the item might be visible but
"greyed out". Administrative privileges might be available locally on
the phone or from a web browser (under password control) and would
probably be granted to some profile content servers. Generally it will
be up to the design of the device which items are under administrative
control, so this does not require any support in profile datasets.
Alternatively a user with administrative privileges might be able to
control whether certain items are under administrative control or user
control, but such settings I would regard as separate configurable
items, e.g., a configurable item to control whether codecs are under
user or administrative control.

2) Items that are not to be displayed to the user. This is generally
limited to passwords, private keys, etc.. A device will generally know
which items fall into this category and will take appropriate
precautions to make it very hard to view these items. So I don't see a
need for an "invisible" attribute.

John

> [mailto:[email-masked]] On Behalf Of Ganesan Sam-W00184
> Sent: 10 March 2008 23:32

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2008 01:43:59 -0400

> From: Dean Willis [mailto:[email-masked]]
>

It was a joke.  I was satirizing the "we can't define invisible data" argument.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 13:20:17 -0700

I fear to suggest anything here but  just as a random idea one might  
consider ....

If you agree there is some configuration that is typically meant for  
an end user of the device to configure, and some that is meant more  
for the administrator, one could have a field that indicates if it is  
"user" or "admin". The policy of who was allowed to change "user" or  
"admin" data would be out of scope of this document  along with any  
enforcement of this policy. This would just be a hint of what a given  
user interface might want to display to different users and would not  
be secured in any way - certainly no trusted computing platform implied.

I'm not sure how much I care one way or the other but just trying to  
suggest an idea that might be acceptable to all.

Cullen <with my individual contributor hat pulled firmly over my eyes>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Fri, 21 Mar 2008 15:36:14 -0500

I agree with Cullen on this:
1) those terms would be of more meaning to the folks that do admin.
2) it is only "invisible" because it is forced by the admin org. and not
because it is marked that way

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings
Sent: Friday, March 21, 2008 4:20 PM
To: Hadriel Kaplan
Cc: sipping
Subject: Re: [Sipping] draft-ietf-sipping-profile-datasets and
"Invisible"

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 21 Mar 2008 14:40:38 -0600

That may be a better way to meet the intention...

- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings
Sent: Friday, March 21, 2008 2:20 PM
To: Hadriel Kaplan
Cc: sipping
Subject: Re: [Sipping] draft-ietf-sipping-profile-datasets and
"Invisible"

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Mar 2008 16:20:53 -0500

> suggest an idea that might be acceptable to all.

I like this approach as a compromise.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Mar 2008 18:31:19 -0400

Sounds good!
Though I was about to suggest if <font size="0"> wasn't acceptable, then maybe <font size="0" color="background" alphabet="ROT13">.  But sure, "user" and "admin" should work too. ;)

-hadriel

> From: Cullen Jennings [mailto:[email-masked]]

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 15:35:48 -0700

Well the other possible compromise would be to split the difference  
and have it invisible half the time and visible the other half. We  
could just use <blink> :)

On Mar 21, 2008, at 3:31 PM, Hadriel Kaplan wrote:

>
> Sounds good!
> Though I was about to suggest if <font size="0"> wasn't acceptable,  
> then maybe <font size="0" color="background" alphabet="ROT13">.  But  
> sure, "user" and "admin" should work too. ;)
>
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Mar 2008 19:47:49 -0400

I just like it. I don't find it to be a compromise of any sort.

	Paul