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

[Cyrus Daboo <[e-mail]>]

Hi Barry,

--On May 7, 2015 at 9:57:05 AM +0100 Barry Leiba <[e-mail]> 
wrote:

> -- Section 8 --
>
>    Clients that support transport layer security as defined by [RFC2818]
>    SHOULD use the "_timezones" service, but MAY use "_timezone" service.
>
> SHOULD/MAY error #1.  The MAY makes << use "_timezone" service >>
> entirely optional either way... which contradicts the SHOULD.  I think
> that what you mean here is that you must use one of these, and there's
> a SHOULD-level preference for a particular one, right?  So:
>
> NEW
>    Clients that support transport layer security as defined by [RFC2818]
>    SHOULD use the "_timezones" service.  It is permissible to use the
>    "_timezone" service instead, but "_timezones" is strongly preferred.
> END
>
> But a question:
>
> *** What does this really mean?  I don't think you're really
> separating the _timezones SRV record from the use of TLS, and
> similarly for _timezone.  I think a client should be using _timezones
> if it's going to use https, and _timezone if it's going to use http
> (non-"s"), right?  You're basically saying that the client SHOULD use
> TLS, and, therefore, the _timezones service.  And the protocol advice
> doesn't really have to do with whether the client *supports* TLS, does
> it?  The client SHOULD use TLS, and one reason not to is that the code
> doesn't support it.  Also, I wonder whether you want to allow for DANE
> here (and perhaps something else that might come later?).
>
> I think something like this is more that you mean here, yes?  (But, of
> course, correct me if this is wrong.):
>
> NEWER (with the subsequent text)
>    Clients SHOULD use transport layer security as defined by [RFC2818],
>    unless they are specifically configured otherwise.  Clients that have
>    been configured to use the TLS-based service, MUST NOT fall back to
>    using the non-TLS service if the TLS-based service is not available.
>    In addition, clients MUST NOT follow HTTP redirect requests from a
>    TLS service to a non-TLS service.  When using TLS, clients MUST verify
>    the identity of the server, using a standard, secure mechanism such as
>    the certificate verification process specified in [RFC6125] or DANE
>    [RFC6698].
> END

That is clearer - thanks.

>    Time zone data servers SHOULD protect themselves against errant or
>    malicious clients by throttling high request rates
>
> I may have lost this battle, but "errant", in its traditional use,
> means "itinerant" or "wandering", not "erroneous".  I think what you
> really mean here is "buggy" (or maybe "badly written", but that's
> harder to put into a document), and maybe you should say that instead.
> But I'm not dying on that hill.  (Similarly for the second use of
> "errant" later in the paragraph.)

I choose to use "poorly implemented" and "problematic" as replacements for 
the first and second uses of "errant".

>    As such, servers MAY require HTTP-
>    based authentication as per [RFC7235].
>
> What's the point of this sentence?  You've already said that they "MAY
> require some form of authentication", and, well, this is HTTP.  I'd
> drop that sentence, because I think it's unnecessary and a
> distraction.

Fixed.

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

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

> -- Section 10.1 --
> *** This appears to be creating a registry, but you haven't told IANA
> that, nor given it a name, nor told them where to put it.  I think you
> should say something more like this:
>
> NEW
> IANA is asked to create a new top-level category called "Time Zone
> Distribution Service (TZDIST) Parameters", and to put all the
> registries created herein into that category.
>
> IANA is asked to create a new registry called "TZDIST Service
> Actions", as defined below.
> END

Fixed.

> -- Section 10.1.1 --
> Nit: "Standards Track", not "Standard Track".

Fixed.

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

> -- Section 10.2 --
> I'm confused about what this is: isn't this giving more information
> about the registry that's in 10.1 and its subsections?  Why is this
> separate from that?  I think 10.2 should be deleted, and 10.2.1 should
> become 10.1.3.

Fixed.

> -- Section 10.3 --
> It's always helpful to make things clear to IANA in the text, and not
> require them to guess from the sectino titles:
>
> NEW
> IANA is asked to make the following registration in the "Well-Known
> URIs" registry:
> END

Fixed.

> -- Section 10.4 --
> Similarly here:
>
> OLD
>    This document registers two new service names as per [RFC6335].  Both
>    are defined within this document.
> NEW
>    IANA is asked to add two new service names to the "Service Name
>    and Transport Protocol Port Number Registry" [RFC6335], as
>    defined below.
> END

Fixed.

> -- Section 10.6 --
> And here:
>
> OLD
>    This document defines the following new iCalendar properties to be
>    added to the registry defined in Section 8.2.3 of [RFC5545]:
> NEW
>    This document defines the following new iCalendar properties to be
>    added to the "Properties" registry under "iCalendar Element
>    Registries" [RFC5545]:
> END

Fixed.

-- 
Cyrus Daboo