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

["Ackermann, Michael" <[e-mail]>]

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:[e-mail]] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 10:48 AM
To: Tom Ritter <[e-mail]>
Cc: IETF TLS <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
On 20 July 2017 at 01:53, Yoav Nir <[e-mail]<mailto:[e-mail]>> wrote:
>
> On 20 Jul 2017, at 8:01, Russ Housley <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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.