[tz] [EXTERNAL] Re: Secure FTP support for IANA downloads

[Robert Elz]

    Date:        Wed, 6 Jun 2018 12:11:47 +0000
    From:        pbassey--- via tz <tz at iana.org>
    Message-ID:  <96177a6b007e41c0bc32c10c034cb447 at SVRP0004CB3B.us.ups.com>

  | Vijay - would this (https download) satisfy the new security requirements?

Unless the need is to hide from others the fact that tz*gz files are being 
downloaded (rather than lists of port number assignments, or ...)
then the download method should really make no difference.

That provides no security against data havnig been (somehow) altered while
on the server (or before it was even uploaded), nor against them being altered
after they have arrived at your system, before they are unpacked.

The signatures that accompany the files, along with the announcement of
their fingerprints when new versions are announced are much better as a
security mechanism - that validates that the data you're about to use is the
exact same data as was originally packaged and distributed from before it
was uploaded (and is totally independent of the path that it took to get to you,
which is really irrelevant, including the possibility that someone has hacked
the DNS, or routing, and the site you end up fetching from is not the actual
IANA site).

What's more, you can retain the .gz files, and verify the signature as often
as you want, and then unpack and compare against the actual data files
that you're using, to verify that nothing (malicious or accidental) has altered
any of the data you're using between tz* releases.   And you can save
the entire thing (signatures, fingerprints, and .gz files) on write-once media
as an audit trail, so you can have a (fairly) permanent record of what was
used, and validate its authenticity years later, should that be needed.

Using secure ftp/http is needed if sensitive (private) data is being 
transferred (for which they work well, incuding verifying that that is
going to or from the site you intended) or when there is no other
protection, and you want what minimal protection they offer that you're
fetching the correct data.

None of that should apply to tz data or code - it is not secret (no-one
is going to attempt to find out the timezone of Bolivia by observing the
tzdata download en route from the server to your system...), as long as
tiy get the correct data, it should not matter where it came from, and the
signatures are a much better validation method that simply knowning that
the data was not altered on the wire.

If some of you work for organisations which have half baked security
policies that don't understand all of this, you'd be much better to attempt
to teach them what really matters, what risks exist, and what techniques
are best, in each case, to overcome those risks, rather than attempting
to get others to modify their systems to accomodate nonsense.

kre

ps: all that said, I totally understand the desire to use some form of FTP
rather than HTTP, it is a much better designed protocol all around, though
considerably more complex.