I can see this is turning into one of "those" discussions; ask a simple
question, go off on seventeen different tangents.
Anyway, some comments interspersed below.
Paul Gilmartin wrote:
<snip>
In a future without tape, if you do not have optical drives and cannot
connect to the Internet, you will need to take a laptop outside the
firewall, download your order, bring it back in, and upload it to your
z/OS system. This is already supported and documented, and has been for
well over a decade now.
I hope it's not a Windows laptop.
How woud you connect it to the M/F for upload?
Anything you can use to get it from the IBM download server into the
z/OS UNIX file system will work. You don't need to set up an FTP server
or anything fancy, just get it there--transferred in binary! I'd choose
FTP from my (Windows, these days) laptop to z/OS, personally, because
it's not that hard to use, and I know how.
Do you expect the firewall to scan the laptop for malware? The more data
you carry in through the firewall, the more likely that some of it is bad.
Many years ago, briefly, IBM delivered PTFs in 3480 cartridges in
polyethylene sleeves proclaiming that malware was thereby excluded.
My peers snickered, "And how hard is it to counterfeit a heat-sealed
plastic envelope?"
If you suspect that a product or service package received from the Internet
contains malware, how does filtering it through the laptop cleanse it?
It does not, of course, but one can scan the file content of a laptop
before bringing it back inside the perimeter, just as one can scan
physical media for the same reason.
SMP/E packages are validated by SHA-1 checksums. Does SHA-1 meet
security criteria nowadays. It's pointless to trust a checksum transmitted
by the same channel as the payload. What are the alternatives?
SMP/E packages sent over the network are so validated, but not those
sent on tape, where we can rely on the hardware for data integrity
checking. I'd have to check on DVD to be sure, but I believe we hash
those, too, for the same reason.
The SHA-1 hash is intended to provide some reasonable assurance that
what we send is what you get, and no more. The FTP(S) and HTTPS
transport layers do not assure data integrity. The notion of tolerating
randomly corrupted z/OS operating system software was, to put it mildly,
"not deemed acceptable." As far as I know, nobody even bothered to ask
Level 2 (smile).
The SHA-1 hash never intended to be interpreted as being a secure hash
for IBM software delivery. Nonetheless, some clients tell us they want
a stronger hash to be used. This is usually not because they don't
understand what we're doing (they generally do), but more often because
their management and auditors do not necessarily want exceptions to a
simple rule.
BTW, if memory serves, NIST deprecated SHA-1 for secure hashes several
years ago. (GIYF if you want to know when.)
There are plenty of alternatives, none of which are implemented today.
The most likely among them seem to be certificate-based, in part because
sending the public key in-band, along with the data to be verified, does
not pose the risk of private key exposure or tampering (which is sort of
the whole point to me, but a crypto guy I am not).
I don't understand certificates. I think they're an institutionalization of
the fad of a couple decades ago, "Please sign my PGP public key."
I need to read up.
There's a bit more to it than that. (Again, a crypto guy I am not. But
you can most likely find intro-level SHARE presentations from people
like Greg Boyd, Eysha Sherrine, and others if you look for them.)
--
John Eells
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
