Subject: Re: [Tzdist] Stephen Farrell's No Objection on draft-ietf-tzdist-caldav-timezone-ref-04: (with COMMENT)

From: Cyrus Daboo <[email-masked]>
Date: Mon, 05 Oct 2015 11:52:20 -0400

Hi Stephen,

--On September 30, 2015 at 6:59:35 AM -0700 Stephen Farrell 
<[email-masked]> wrote:

> - 3.1.2: The tzdist protocol says clients SHOULD use TLS. A
> question then is ought servers here (be able to) include trust
> point information for tzdist for the service in question when
> they tell a client to use a particular tzdist service?

As in the CalDAV server includes some certificate information about the 
tzdist servers it connects to, so the clients can verify they see the same 
details when they connect? I think that is probably going a step too far 
given all the usual requirements to verify the tzdist service certs.

> - Given the three points below, maybe it is worth specifying
> some 'background' kind of traffic to be sent between client and
> tzdist services? What do you think?
>
> - section 4, point 5: that seems onerous - is a client supposed
> to retrieve all known timezones from all servers?  What if/when
> those change?

The client definitely needs to retrive the full time zone data for any time 
zones it is using in calendar data - there is no way around that. Beyond 
that they are really not required to retrive all time zone data. For those 
time zones they do retrive, they do need to keep those up to date by 
following suggestions in the tzdist protocol spec.

> - section 8: missing privacy issue: if I create an event using a
> weird TZ and can see who accesses the tzdist service, then I can
> find out who is subscribed to some calendars maybe. Worth
> noting? I don't see what can be done about it, except maybe to
> ask clients to occasionally make a random query to the tzdist
> service just to confuse matters, but that'd also have downsides
> if not done well.

I will add a new Privacy Considerations section that references the tzdist 
protocol privacy section (which is very comprehensive):

9.  Privacy Considerations

   The privacy recommendations in Section 9 of the Time Zone Data
   Distribution Service [I-D.ietf-tzdist-service] specification SHOULD
   be used to ensure that details of clients' interactions with CalDAV
   servers are not exposed to potential network observers.

> - section 8: missing security issue: if a lot of clients are
> fetching this information from a tzdist server, then that
> becomes an interesting thing to attack as the consequences could
> be significant. Maybe worth noting just to encourage folks to
> (document their code so as to get others to) think about this
> when deploying.

I can add the following as a new paragraph in the security considerations:

   This specifications adds Time Zone Data Distribution Service
   [I-D.ietf-tzdist-service] servers into the overall calendaring and
   scheduling client/server architecture, as a critical component, and
   thus adds a new vector of attack against such systems.  As such,
   administrators of CalDAV servers SHOULD ensure that any advertised
   time zone distribution servers are protected by a level of security
   commensurate with all the other components in the system.

-- 
Cyrus Daboo

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Oct 2015 17:23:25 +0100

Hiya,

All below is good, couple of notes below but no pressing need to
follow up further - handling it as you suggest is good.

On 05/10/15 16:52, Cyrus Daboo wrote:
> tzdist servers it connects to, so the clients can verify they see the
> same details when they connect? I think that is probably going a step
> too far given all the usual requirements to verify the tzdist service
> certs.

Fair enough. It wouldn't be what's usually done, true. It might be
better though if (in general) we moved from naming via DNS to naming
via DNS+some keying material. But that'd probably be better done
when more major changes are being made.

>> tzdist services? What do you think?

I note you didn't answer here, but that's ok. A separate spec
(e.g. "privacy friendly guidelines for developing caldav clients")
could be developed for that (or for caldav in general) at some
other time I guess.

> The client definitely needs to retrive the full time zone data for any
> time zones it is using in calendar data - there is no way around that.
> Beyond that they are really not required to retrive all time zone data.
> For those time zones they do retrive, they do need to keep those up to
> date by following suggestions in the tzdist protocol spec.
> 
> I will add a new Privacy Considerations section that references the
> tzdist protocol privacy section (which is very comprehensive):
> 

That's good but I do think there's a new twist here. The 9th
bullet in that reference does talk about a fake TZ for tracking
but only says a server could do that. With this spec, I think
we're extending the issue to anyone who can create an event
(if a server supports an unknown TZ or if we just use a lesser
used TZ). If I'm right there, then I'd argue to maybe recognise
that here, e.g. by adding something like "This specification
extends the potential privacy issues discussed in [service]
to anyone who can create a calendar event e.g. with a fake or
lesser-used TZ."

>   commensurate with all the other components in the system.

Nice.

Cheers,
S.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 08 Oct 2015 14:28:21 -0400

Hi Eliot,

--On October 5, 2015 at 4:49:15 PM +0000 "Eliot Lear (elear)" 
<[email-masked]> wrote:

>
> I'm on vacation and don't have the spec in front of me. It would seem
> reasonable to mention as a mitigation to the attack Stephen mentioned to
> only query after an authorization step. What that step is could be a one
> time query by the MUA  like "allow invitations from senders from this
> domain for?" Or it could be some MTA rule.

I am not sure such a statement belongs in this document as that behavior is 
true for arbitrary invites being sent from any untrusted source, 
irrespective of whether timezones-by-reference is being used. There is 
already a fair amount of security covered in RFC5546 (iTIP - iCalendar 
invite).

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 08 Oct 2015 15:15:04 -0400

Hi Eliot,

--On October 8, 2015 at 7:03:58 PM +0000 "Eliot Lear (elear)" 
<[email-masked]> wrote:

> Thanks Cyrus. A mention of the threat that Stephen mentions and then a
> reference should do, then. No?

OK, how about I add this (based on the text Stephen suggested) to the end 
of the Privacy section:

   Note that
   this specification extends the potential privacy issues discussed in
   [I-D.ietf-tzdist-service] since events can be delivered to a calendar
   user from an outside source (e.g., using iTIP [RFC5546]), and an
   attacker could create a calendar event with, e.g., a fake or lesser-
   used time zone identifier, that could be used to monitor the calendar
   user's activity and interaction with others.

-- 
Cyrus Daboo

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Oct 2015 11:06:52 +0100

Looks good, thanks,
S

On 08/10/15 23:20, Eliot Lear (elear) wrote:
> Sorry. Yes but reference the remediation. 
> 
> Eliot
> 
>> On Oct 8, 2015, at 3:15 PM, Cyrus Daboo <[email-masked]> wrote:
>>
>> Hi Eliot,
>>
>> --On October 8, 2015 at 7:03:58 PM +0000 "Eliot Lear (elear)" <[email-masked]> wrote:
>>
>> OK, how about I add this (based on the text Stephen suggested) to the end of the Privacy section:
>>
>>  Note that

---

From: Barry Leiba <[email-masked]>
Date: Mon, 12 Oct 2015 20:01:44 -0700

Cyrus,
Looks like we just need a revised I-D and this is ready, yes?

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 Oct 2015 11:34:07 -0400

Hi Barry,

> Looks like we just need a revised I-D and this is ready, yes?

I just posted the -05 draft with the updates to address the IESG review,

-- 
Cyrus Daboo