Re: [Tzdist] AD review of draft-ietf-tzdist-service-07 - Sections 8 - 10

[Daniel Migault <[e-mail]>]

Hi, 

Please see my comments inline.

BR,
Daniel

> -- Section 9 --
>
>    3.  Always fetch and synchronize the entire set of time zone data to
>        avoid leaking information about which time zones are actually in
>        use by the client.
>
> *** Really?  Wow.  That's sorta like saying that web clients should 
> fetch hundreds of randomly selected web sites along with the one 
> they're actually intending to retrieve, in order to hide what the user 
> is asking for.  It sounds like really bad advice to me.  If you're 
> using TLS, don't you have this taken care of that way?  Is it *really* 
> good advice for the client to fetch a lot of time zone data that it 
> doesn't and probably never will need?

There was a thorough security/privacy review by Daniel Kahn Gillmor that lead to the current text in Section 9 (see tzdist mailing messages with "[saag]" in the subject).

I think some of these precautions are there to cover those who take privacy very seriously - but it is only advice and not a requirement

DANIEL: Maybe we should add a note on the counter effect.  Maybe one could also mention that this could be mitigated by tzdist resolvers that would work on behalf of stub tzdist clients. -- left for future.

> Similarly for other advice: if the client follows (1), does it really 
> need to worry about (4)?  Or (5) or (6)?

For (4), yes, because each individual time zone might have a unique fingerprint (sizes differ) and that could be exposed via traffic analysis even with TLS in use. (5) and (6) (and also (4) are about tracking by untrusted servers and is relevant no matter whether TLS is being used.

> I don't understand (7) at all: won't the client use authenticated HTTP 
> requests if and only if the server requires them?

Again this is advice about untrusted servers. If you already signed-up with a service that requires authentication, then yes it is possible to argue that you have already agreed to trust it in some respects, so this advice might not be so relevant. But perhaps the untrusted server could prompt for some kind of 3rd party authentication (maybe OAuth)

> What threat is (9) really trying to address, which isn't already 
> exposed by the fact that the server has the client's IP address and 
> might even be requiring the client to log in?

Well the point is the client's IP address can vary, but the fingerprinting described in (9) would allow a server to uniquely identify the client machine, even with a varying IP address.

Anyway, I am not sure, beyond some small clarifications, if anything needs to change in this section. Certainly it needs input from SAAG/Security ADs if we do decide to make changes now. Perhaps this should be left to an IETF wide review (with another call to SAAG folks to pay attention to it)?

DANIEL: I also believe clarifications would be sufficient, so people that have not followed the whole discussion can have a good understanding of the issues. There are two aspects in these considerations: 1) First pointing out the information that may leak and 2) Second possible mitigations. At some point the mitigation may look "suprising". It is good to clearly state these are possible ways to mitigate, and these are up to the client or server to implement these recommendations. Implementation may be balanced with other aspects. Even though they may look surprising I believe they can be useful  to understand the scope of the issue.


> *** You're specifying a Standards Track RFC *and* review by a 
> designated expert.  Why do you need both?  Presumably, time zone 
> experts in the IETF (such as the participant whom the IESG might
> designate) will be participating in the consensus process anyway.  Why 
> is it good to set up a situation wherein one individual is empowered 
> to override (rather than to participate in and influence) IETF 
> consensus?
>
> Small thing: If you want a Standards Track RFC to be required, you 
> should say that the registration policy is "Standards Action", and 
> reference RFC 5226.  If you do *also* want a designated expert, you 
> should use "Standards Action and Expert Review", and you should 
> specify instructions for the designated expert.
>
> *** The instructions to the DE should explain what the DE should be 
> considering, and when it's appropriate to decline a registration 
> request ("reject with cause", in your terminology).  It's not 
> acceptable to give a designated expert license to reject a request 
> without any guidance about when that's appropriate.

If others are OK with it, I would be willing to just go with "Specification Required" (as per RFC5226) and provide suitable instructions for the designated expert.

DANIEL: I am fine with that too.

--
Cyrus Daboo

_______________________________________________
Tzdist mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tzdist