Re: [ietf-privacy] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05

[Daniel Kahn Gillmor <[e-mail]>]

Hi Eliot--

thanks for the feedback.

On Sat 2015-01-31 07:08:26 -0500, Eliot Lear wrote:

> I think there are several categories of issues that you've raised, and
> I'd like to break them out.  The first is the easy category: that which
> has been raised before and considered.  There is only one issue in that
> category as to whether or not everything should run atop TLS.  That
> issue need not be reconsidered, EXCEPT in as much as you have clarified
> the context (c2s versus s2s).

Clarifying the c2s vs. s2s scenarios for TLS would definitely be useful.

> There is another category of that which really must change.  Most (if
> not all) of what you mark as security is in this category.  The
> downgrade attack that is possible in the current text also does not
> match my understanding of the consensus of the working group.  That is-
> either a client uses HTTP or it uses HTTPS, but it may not "try" HTTPS
> first, and then back off to HTTP.  "Do.  Do not.  There is no try."

If we can spell this out explicitly in the draft, that would be good.  I
wonder if this is maybe something that would contribute to the idea of
"profiles of operation".  If there is a profile for low-power,
in-network devices, that profile could allow HTTP access, restricting
fetches from the local network's tzdist provider, and accept the
linkability implications (and the resulting lack of privacy for the
device).

This would suggest a second profile for other devices: those that have
higher bandwidth available, more compute power, and should not be
willing to make the linkability/privacy tradeoff in the same way.

Is there a third profile, some sort of device, service, or operating
system that fits in the middle here?  Naming the profiles explicitly and
being clear which features of the spec are intended for which profile
might make the privacy considerations easier to write.

It might also turn out that there are features that fit in no realistic
profile, and can therefore be dropped to simplify the spec.

> The other issues break down into two groups, I think.  Authenticated
> sessions versus unauthenticated sessions.  Because authentication is
> allowed, and because we do not specify a provisioning mechanism, likely
> there will be linkage between services.  But we should also be mindful
> of what mitigations are truly available to us with regard to the other
> functions.

Authenticated sessions clearly provide linkability between repeat
sessions of the same client to the server.  Depending on other choices
made by the network configurations involved (e.g. the use of stable TLS
session IDs, or padding/timeskew choices), those sessions may
*also* leak some linkable information to a passive network attacker (i
haven't yet considered an active network attacker whose goal is to link
sessions).

But unauthenticated sessions are not necessarily unlinkable, either to
the Provider, or to a network observer.  If the goal is unlinkability,
unauthenticated sessions are probably necessary but not sufficient.
It's important that the draft be clear about this.

          --dkg