Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

[Alex C <[e-mail]>]

If the embedded device is capable of running TLS anyway (e.g. fast enough
to do RSA) why not have the phone act as a dumb proxy?

However I see the draft has some additional scenarios where it makes sense,
such as where the device must work with an off-the-shelf proxy that only
speaks HTTP.

On Wed, Nov 8, 2017 at 4:15 AM, Hannes Tschofenig <[e-mail]
> wrote:

> FWIW: I can tell you what the threat model was with the layered TLS work.
>
> Let me give you a very specific example. Imagine a Bluetooth Low Energy
> device that communicates via a phone to a cloud-based service. The
> communication from the phone to the cloud uses HTTPS. The communication
> from the BLE device to the phone uses ordinary BLE
> services/characteristics.
>
> The Layered TLS/application layer TLS would in this case run from the
> BLE device all the way to the cloud-based service at the application layer.
>
> This allows us to provide end-to-end security across a proxy (in this
> case the phone) and independent of the underlying protocols.
>
> Does this make sense?
>
> Ciao
> Hannes
>
>
> On 11/07/2017 10:21 AM, Alex C wrote:
> > What exactly is the threat model here?
> >
> > Are you trying to hide a connection from a reverse proxy at the server
> > end? If so, the server operator should not have deployed a reverse proxy
> > in the first place.
> >
> > Are you trying to hide from a MITM proxy that supplies its own
> > certificate? If so, then what prevents the proxy from doing the same to
> > the tunnelled session?
> > When MITM proxies learn to do that, will we create another tunnelling
> > protocol inside this one?
> >
> > This is a cat-and-mouse game with middleboxes (much like the version
> > negotiation problem, but in a different way). Keep playing and everyone
> > loses.
> >
> > On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hey TLS folks,
> >
> >     Owen, Max, and I have been kicking around some ideas for how to make
> >     secure connections in environments where HTTPS is subject to MitM /
> >     proxying.
> >
> >     The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
> >     creating a channel you could use when you really need things to be
> >     private, even from the local MitM.
> >
> >     Feedback obviously very welcome.  Interested in whether folks think
> >     this is a useful area in which to develop an RFC, and any thoughts
> >     on how to do this better.
> >
> >     Thanks,
> >     --Richard
> >
> >
> >     On Mon, Oct 30, 2017 at 3:47 PM, <[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >
> >
> >         A new version of I-D, draft-friel-tls-over-http-00.txt
> >         has been successfully submitted by Owen Friel and posted to the
> >         IETF repository.
> >
> >         Name:           draft-friel-tls-over-http
> >         Revision:       00
> >         Title:          Application-Layer TLS
> >         Document date:  2017-10-30
> >         Group:          Individual Submission
> >         Pages:          20
> >         URL:
> >         https://www.ietf.org/internet-drafts/draft-friel-tls-over-
> http-00.txt
> >         <https://www.ietf.org/internet-drafts/draft-friel-
> tls-over-http-00.txt>
> >         Status:
> >          https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
> >         <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/>
> >         Htmlized:
> >          https://tools.ietf.org/html/draft-friel-tls-over-http-00
> >         <https://tools.ietf.org/html/draft-friel-tls-over-http-00>
> >         Htmlized:
> >          https://datatracker.ietf.org/doc/html/draft-friel-tls-over-
> http-00
> >         <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-
> http-00>
> >
> >
> >         Abstract:
> >            Many clients need to establish secure connections to
> application
> >            services but face challenges establishing these connections
> >         due to
> >            the presence of middleboxes that terminate TLS connections
> >         from the
> >            client and restablish new TLS connections to the service.
> This
> >            document defines a mechanism for transporting TLS records in
> HTTP
> >            message bodies between clients and services.  This enables
> >         clients
> >            and services to establish secure connections using TLS at the
> >            application layer, and treat any middleboxes that are
> >         intercepting
> >            traffic at the network layer as untrusted transport.  In
> >         short, this
> >            mechanism moves the TLS handshake up the OSI stack to the
> >         application
> >            layer.
> >
> >
> >
> >
> >         Please note that it may take a couple of minutes from the time
> >         of submission
> >         until the htmlized version and diff are available at
> >         tools.ietf.org <http://tools.ietf.org>.
> >
> >         The IETF Secretariat
> >
> >
> >
> >     _______________________________________________
> >     TLS mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/tls
> >     <https://www.ietf.org/mailman/listinfo/tls>
> >
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
>