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
>