Re: [TLS] Is there a way forward after today's hum?

As I said in the previous message, the 3270 was the original web browser.
What I mean by that is that the 3270 transaction model is basically a
primitive version of http: you throw up a page, the user enters some data,
then the user hits send and all the data goes to the server at once.   The
reason the 3270 is no longer widely used is because it's been replaced by
web browsers.

Mentioning that in passing probably made my message less clear; the point
is that the 3270<->mainframe model of operation comes with very different
assumptions than the web browser<->service provider model, and one of the
problems you have is that what you are doing is really the former and not
the latter.

On Fri, Jul 21, 2017 at 12:00 PM, Ackermann, Michael <MAckermann@bcbsm.com>
wrote:

> Ted
>
> You may be aware that most enterprises have been migrating away from 3270
> for 20 years or more.  Very little still exists.      What little does
> exist is usually implemented via tn3270.   In the browser scenario you
> describe I would expect the Server side to be a tn3270 server,  but you
> will have to fill in the details of the use case you are describing,  to be
> sure.
>
>
>
> I hope the above helps,  but my real question is why would this be special
> or even relevant to the TLS1.3 discussion.
>
>
>
> Attempting to address specific applications or implementations would seem
> only add confusion IMHO.
>
>
>
> Thanks
>
>
>
> Mike
>
>
>
>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 10:48 AM
> *To:* Tom Ritter <tom@ritter.vg>
> *Cc:* IETF TLS <tls@ietf.org>
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> The problem is that one of the applications for web browsers is as a
> replacement for 3270s (the first web browser).   That use case is said to
> require this functionality.
>
>
>
> On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter <tom@ritter.vg> wrote:
>
> On 20 July 2017 at 01:53, Yoav Nir <ynir.ietf@gmail.com> wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley <housley@vigilsec.com> wrote:
> >
> > Ted, if we use a new extension, then the server cannot include it unless
> the
> > client offered it first.  I am thinking of an approach where the server
> > would include information needed by the decryptor in the response.  So,
> if
> > the client did not offer the extension, it would be a TLS protocol
> violation
> > for the server to include it.
> >
> >
> > So we also add an alert called “key-export-needed” in case the client
> does
> > not include it.
> >
> > That way a browser (as an example) can show the user why the connection
> was
> > broken (“server requires wiretapping to be enabled. Go to about:config if
> > that is OK and change the allow-wiretap setting to True”)
>
> I previously expressed that I could support the extension mechanism -
> I'm sympathetic to regulatory requirements and unhappy with, although
> understanding of, what has become the 'standard mechanism' (breaking
> crypto) to achieve them. I've looked at more than one 'end to end'
> encrypted messenger that tosses in the 'third end' of key escrow.
>
> But to suggest such a mechanism might ever be implemented in a web
> browser throws my hackles up. The discussion has always been about
> datacenter - the people concerned say "We don't want your datacenter
> stuff in our protocol and the proponents say "No really, we only care
> about the datacenter."
>
> The concerns around some future government-mandated key escrow is very
> real and very concerning.
>
> -tom
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>