Subject: Re: [Gen-art] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt

From: Cyrus Daboo <[email-masked]>
Date: Mon, 12 Oct 2009 21:16:49 -0700

Hi Brian,
Thank you for your review. Sorry I have been busy on other subjects these 
last few weeks and am only now getting around to replying.

--On September 21, 2009 10:34:33 AM +1200 Brian E Carpenter 
<[email-masked]> wrote:

> Major issues:
> -------------
>
> I would have liked to see a bit more emphasis on privacy issues in the
> Security Considerations. In particular, shouldn't there be a fairly
> strong SHOULD obligation on clients to implement TLS and use it by
> default? The way the text is written, a client running with no TLS and no
> HTTP Basic authentication appears to be allowed.

There are cases where public address books (or a public address service) 
can be used, and there is no absolute requirement that TLS be used in such 
cases (or maybe the IESG has a requirement that no plain text whatsoever 
can be sent in any protocol).

That said I would be OK with adding the following to the end of the first 
paragraph in Security Considerations:

    Clients SHOULD use TLS whenever possible.

Is that sufficient?

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

-- 
Cyrus Daboo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Oct 2009 14:43:43 +1300

Hi Cyrus,

On 2009-10-13 17:16, Cyrus Daboo wrote:
> Hi Brian,
> Thank you for your review. Sorry I have been busy on other subjects
> these last few weeks and am only now getting around to replying.
> 
> can be used, and there is no absolute requirement that TLS be used in
> such cases (or maybe the IESG has a requirement that no plain text
> whatsoever can be sent in any protocol).
> 
> That said I would be OK with adding the following to the end of the
> first paragraph in Security Considerations:
> 

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

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.

Thanks
    Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 13 Oct 2009 11:54:39 +0100

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

>followed the IETF standard, says XYZ spokesman.") I think it needs a
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).

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 15 Oct 2009 09:51:01 -0400

Hi Alexey,

> I wonder if this needs to be phrased as "Clients MUST implement TLS

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.

>> 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.
>>
>>
> 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: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Oct 2009 15:31:56 +0100

Cyrus Daboo wrote:

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

Leaving "client SHOULD use TLS" would be Ok with me, but the rest of 
IESG might disagree.

So anyway, I've added this as an RFC Editor note.

>> well

I like that. Added as an RFC Editor note.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 15 Oct 2009 13:32:47 -0400

these changes are enough important that we must have wg review on this 
before proceeding further. I suggest we should bring this (SHOULD/MUST 
TLS) to the wg.

Marc.

Cyrus Daboo a écrit :
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2009 09:01:43 +1300

I'm happy with the proposed changes, as far as my review
goes. I agree with Marc, it seems correct to verify such
changes in normative requirements with the WG.

   Brian

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 15 Oct 2009 16:11:09 -0400

Hi Brian,

> changes in normative requirements with the WG.

Email has been sent to the WG list.

-- 
Cyrus Daboo