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

[Hannes Tschofenig <[e-mail]>]

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
>