Subject: Re: [VCARDDAV] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt (fwd)

From: Cyrus Daboo <[email-masked]>
Date: Thu, 15 Oct 2009 15:43:37 -0400

Hi folks,
The GenART review of CardDAV brought up two issues for which I have 
proposed resolutions as documented below. Both of these are considered 
changes that we need WG consensus on.

1) The first point relates to a requirement for clients to support TLS. 
Currently the spec says nothing except that servers MUST support it. I 
propose added a statement that clients SHOULD support TLS. There was some 
debate as to whether that ought to be a MUST. Please comment.

2) The second point relates to "warnings" in clients when contact data is 
made "public". The current text states that clients MAY warn users in such 
cases. It was felt this was too weak. I have proposed some alternative text 
(seen at the bottom of the forwarded message below) that turns the MAY into 
a SHOULD and clarifies a bit more under what circumstances this might 
occur. Please comment.

------------ Forwarded Message -----------
Date: October 15, 2009 9:51:01 AM -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Brian E Carpenter 
<[email-masked]>
cc: [email-masked], General Area Review Team 
<[email-masked]>, [email-masked]
Subject: Re: Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt

Hi Alexey,

--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
<[email-masked]> wrote:

>> I would be happy with that; it's probably something to be checked with
>> the WG since it's a change in normative requirements.
>>
>>
> I wonder if this needs to be phrased as "Clients MUST implement TLS
> support, SHOULD use it"?

I think MUST is too strong. There a situations where a client may exist on
a private network (e.g. a server farm with a carddav server and a webapp
accessing it) where there is no need for TLS, or they may exist in an
environment where some other form of security layer is present (e.g.
ipsec). Implementors of such clients should not be burdening with
implementing TLS if they don't need it.

>>>> On the same lines,
>>>>
>>>>   Clients MAY choose to warn users when they create address data in a
>>>>   public address book, copy or move address data into public address
>>>>   books, or change access privileges in such a way as to expose address
>>>>   data to unauthenticated users.
>>>>
>>>> Why isn't that a SHOULD?
>>>>
>>>>
>>> I am a little nervous about putting such a requirement on a client.
>>> First of all, what does it really mean to "warn" a user? An alert, an
>>> icon, a noise? Does it happen only the first time they do an action, or
>>> each time? SHOULD seems a little strong when the nature of the warning
>>> is really going to be implementation dependent.
>>>
>>> That said, if there is consensus for this change, it may be necessary to
>>> explain a little more what "warn" means.
>>>
>>>
>> Yes, that is a problem. I'm not a privacy expert, but it does seem like
>> something that could one day end up as bad news. ("XYZ Corporation
>> revealed private data for 27,000 customers, FCC investigation alleges.
>> We just followed the IETF standard, says XYZ spokesman.") I think it
>> needs a little thought.
>>
>>
> I think SHOULD is better here.
> And yes, I think some explanation of what "warns" mean is needed, as well
> as some possible description of "remember my answer" checkbox (or
> similar).

OK, I can change that paragraph to

    Clients SHOULD warn users in an appropriate fashion when they copy or
    move address data from a private address book to a shared address book
    (one accessible by other authenticated users only) or public address
    book (one accessible by unauthenticated users). Clients SHOULD provide
    a clear indication as to which address books are private, shared or
    public. Clients SHOULD provide an appropriate warning when changing
    access privileges for a private or shared address book with data so as
    to allow unauthenticated users access.

Is that reasonable?

-- 
Cyrus Daboo

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

Subject: Re: Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Brian E Carpenter <[email-masked]>
Cc: [email-masked], General Area Review Team <[email-masked]>, [email-masked]
Date: Thu, 15 Oct 2009 09:51:01 -0400

Hi Alexey,

--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>> I would be happy with that; it's probably something to be checked with
>> the WG since it's a change in normative requirements.
>>
>>
> I wonder if this needs to be phrased as "Clients MUST implement TLS
> support, SHOULD use it"?

I think MUST is too strong. There a situations where a client may exist on 
a private network (e.g. a server farm with a carddav server and a webapp 
accessing it) where there is no need for TLS, or they may exist in an 
environment where some other form of security layer is present (e.g. 
ipsec). Implementors of such clients should not be burdening with 
implementing TLS if they don't need it.

>>>> On the same lines,
>>>>
>>>>   Clients MAY choose to warn users when they create address data in a
>>>>   public address book, copy or move address data into public address
>>>>   books, or change access privileges in such a way as to expose address
>>>>   data to unauthenticated users.
>>>>
>>>> Why isn't that a SHOULD?
>>>>
>>>>
>>> I am a little nervous about putting such a requirement on a client.
>>> First of all, what does it really mean to "warn" a user? An alert, an
>>> icon, a noise? Does it happen only the first time they do an action, or
>>> each time? SHOULD seems a little strong when the nature of the warning
>>> is really going to be implementation dependent.
>>>
>>> That said, if there is consensus for this change, it may be necessary to
>>> explain a little more what "warn" means.
>>>
>>>
>> Yes, that is a problem. I'm not a privacy expert, but it does seem like
>> something that could one day end up as bad news. ("XYZ Corporation
>> revealed private data for 27,000 customers, FCC investigation alleges.
>> We just followed the IETF standard, says XYZ spokesman.") I think it
>> needs a little thought.
>>
>>
> I think SHOULD is better here.
> And yes, I think some explanation of what "warns" mean is needed, as well
> as some possible description of "remember my answer" checkbox (or
> similar).

OK, I can change that paragraph to

    Clients SHOULD warn users in an appropriate fashion when they copy or
    move address data from a private address book to a shared address book
    (one accessible by other authenticated users only) or public address
    book (one accessible by unauthenticated users). Clients SHOULD provide
    a clear indication as to which address books are private, shared or
    public. Clients SHOULD provide an appropriate warning when changing
    access privileges for a private or shared address book with data so as
    to allow unauthenticated users access.

Is that reasonable?

-- 
Cyrus Daboo

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 16 Oct 2009 10:49:16 -0300

Cyrus Daboo wrote:

> debate as to whether that ought to be a MUST. Please comment..

+1. I think the situation described below should be explictly stated in order 
to clarify the meaning of the SHOULD and illustrate some situations in which 
ignoring this requirement might be appropriate .

BTW, If the consensus were keeping the MUST, note that TLS is described as 
optional in several sections (e.g. section 11 and 13).

> a SHOULD and clarifies a bit more under what circumstances this might

+1. The proposed text works for me.

Regards

Javier

>    to allow unauthenticated users access.

--------------------------------------------------------------------------------

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

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 16 Oct 2009 10:30:32 -0400

Hi Javier,

--On October 16, 2009 10:49:16 AM -0300 Javier Godoy 
<[email-masked]> wrote:

> +1. I think the situation described below should be explictly stated in
> order to clarify the meaning of the SHOULD and illustrate some situations
> in which ignoring this requirement might be appropriate .
>
> BTW, If the consensus were keeping the MUST, note that TLS is described
> as optional in several sections (e.g. section 11 and 13).

Alexey's text proposes that for clients support of TLS is a MUST, but use 
of it is a SHOULD. i.e., it is still optional to actually use TLS, but 
clients have to provide the capability so users can choose to use it if 
they want.

I believe support of TLS ought to be a SHOULD due to the various reasons I 
listed.

So let me make a more concrete text proposal for what I propose:

    Clients SHOULD support TLS. In most cases TLS SHOULD be used by
    clients, though in some situations, e.g., where some other form of
    security is known to be in place, it need not be supported or used.

I think Alexey's suggestion just boils down to this:

    Clients MUST support TLS, and SHOULD use it.

So we need consensus on which of the above two proposed text changes we 
should adopt (or another proposal).

-- 
Cyrus Daboo