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 <[email protected] > 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 <[email protected] > > <mailto:[email protected]>> 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, <[email protected] > > <mailto:[email protected]>> 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 > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > > > > > > > > > _______________________________________________ > > TLS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
