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 <r...@ipv.sx > <mailto:r...@ipv.sx>> 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, <internet-dra...@ietf.org > <mailto:internet-dra...@ietf.org>> 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 > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
