Tom, I believe you have nailed it exactly. Those are the two main drivers IMHO.
In addition, there is a *huge* problem (in general, not Z specifically) of poorly-written programmatic "users" of TLS libraries. If you write a General Ledger program and the ledgers don't cross-foot, the CFO tells you. If you write an "encrypted" communication program and the encryption has a logical flaw, generally no one tells you. :-( Centralizing the use of TLS, not just the TLS APIs, is a step toward addressing that problem. https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Tuesday, June 30, 2020 9:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AT-TLS ? Very Basic Questions Thanks KB... I think I got my basic question answered, which is that one thing AT-TLS was designed for is to encrypt data for TCP/IP programs that weren't originally written with encryption. In addition, it sounds like even programs that can do their own encryption (i.e. TN3270) can also use AT-TLS. If so, that's a smart plan - putting encryption processing in one bucket with one set of controls, and one spot to update when TLS1.x comes along. But if I'm wrong with any of the general notes above, please correct me. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
