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

[Ben Schwartz <[e-mail]>]

On Tue, Oct 31, 2017 at 5:03 PM, Owen Friel (ofriel) <[e-mail]>
wrote:

>
>
>
>
> *From:* TLS [mailto:[e-mail]] *On Behalf Of *Ben Schwartz
> *Sent:* 31 October 2017 01:35
> *To:* Richard Barnes <[e-mail]>
> *Cc:* <[e-mail]> <[e-mail]>
> *Subject:* Re: [TLS] New Version Notification for
> draft-friel-tls-over-http-00.txt
>
>
>
> On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes <[e-mail]> wrote:
>
> It requires awareness in the following sense: If by chance the client is
> in a nice, open network and the base TLS connection goes directly to the
> server, CONNECT is kind of unnatural; you would want the client to do
> something different in that case.
>
>
>
> Surely this is equally true/untrue of ATLS.  Why do double-TLS if it can
> be avoided?  But then, how does the application know whether to do ATLS
> encapsulation?  It's the same question in both cases.
>
> *[ofriel] The draft does state “*As an optimisation, clients may choose to only use ATLS as a fallback
>
>    mechanism if certificate validation fails on the transport layer TLS
>
>    connection to the service
>
> *”*
>
> *It should be easy for a device to detect the presence of a middlebox if
> the network layer TLS connection presents a service certificate that has
> the expected SAN/CN, but is signed by an unexpected/untrusted CA (i.e. one
> not baked into/explicitly configured on the device).*
>

Yes, but the client could equally well fall back to HTTP CONNECT in this
case.  My comments are all directed to the question of why to use ATLS
instead of an existing solution, such as "TLS over HTTP CONNECT".


>
>
>   You're correct that you *could* configure the server to handle connect
> properly, but all of the options for doing this are kind of cumbersome --
> either you have to stick a possibly-unnecessary proxy in front of the
> server, or handle CONNECT on the server, which is not really well-supported
> by web application frameworks.  By contrast, running data over POST is
> ubiquitous.
>
>
>
> This makes a certain amount of sense to me.  If it were up to me, rather
> than design a TLS-specific transport, I'd be more inclined to propose a
> standardized version of something like Crowbar
> <https://github.com/q3k/crowbar>.
>
> *[ofriel] /me reads. ‘like’ appears to be the operative word here based on
> author comments on https://github.com/q3k/crowbar
> <https://github.com/q3k/crowbar>: “*Crowbar *DOES NOT PROVIDE ANY DATA
> CONFIDENTIALITY**”*
>

Yes, but "TLS over Crowbar" does provide confidentiality, and that is the
alternative to ATLS that I am proposing in this sentence.

(Or just document that reverse proxies and frameworks ought to do something
> reasonable with CONNECT.
>
> *[ofriel] CONNECT would just open a tunnel to get packets through the
> proxy to the service, but would require the proxy to *not* attempt to do
> TLS interception, which is exactly what we are trying to allow. If policy
> dictates that everything must be intercepted, this mechanism enables that.*
>

I don't understand which proxy you're referring to, or how this
distinguishes ATLS from "TLS over HTTP CONNECT".

)  Otherwise this seems to be ossifying the proxy, privileging TLS and
> preventing deployment of Noise protocol <http://noiseprotocol.org/> or
> whatever the future may hold.
>
> *[ofriel] One of the reason for blindly transporting TLS and not in any
> way restricting or customising the TLS records transferred was to be future
> compatible with all future versions of TLS; and also to allow an
> application to leverage a single software library for both network
> transport and application crypto exchanges.*
>

OK, but you can be even more abstracted by simply transporting a
byte-stream, and letting the application developer choose what protocol to
speak in that stream.  This shares even more code between the "network" and
"application" usage of TLS, since they both flow over bytestream
abstractions (no need to expose the TLS record layer).

> It was also pointed to me off-list that you can generate POST requests
> from Javascript in XHR, but not CONNECT requests.  So doing this over POSTs
> also makes it accessible to web apps.  (`emscripten libssl.a` left as an
> exercise to the reader.)
>
>
>
> It seems your threat model assumes an adversary who is an active
> intermediary in your HTTP session.  If so, then this wouldn't seem to
> protect the user against the threat.
>
> *[ofriel] Can you clarify why this doesn’t protect against an active
> intermediary in the HTTP session? Transferring the TLS records payloads in
> HTTP bodies is directly analogous to  transferring TLS records over
> untrusted TCP network transport.*
>

In a "web app", the emscripten-compiled copy of libssl would necessarily be
transmitted over the insecure HTTP connection that also contains ATLS.  An
active intermediary therefore could, for example, replace the library with
a modified version that uses a broken PRNG.


>
>
>
>
>
>
> --Richard
>
>
>
>
>
> On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz <[e-mail]> wrote:
>
> I don't understand why ATLS allows the app to be less "aware" than HTTP
> CONNECT.  I also don't understand how an ATLS client is closer to "one code
> path" than HTTP CONNECT.  It seems to me that your description of client
> behavior applies equally to ATLS and HTTP CONNECT.
>
>
>
> On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes <[e-mail]> wrote:
>
> But I agree, it would be good to have some more clarity around use cases
> and why not other solutions.
>
>
>
> On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes <[e-mail]> wrote:
>
> HTTP CONNECT is not great for some use cases because it requires the app
> to be aware that it's dealing with a proxy.  It's simpler if you can just
> have one code path that works whether your TLS is intermediated or not.
> With the solution outlined in the draft, you can just always ignore the
> certificate the server sends in the first TLS connection (because it might
> be from a MitM), and then do all your cert validation, pin checks, etc. at
> the application layer.
>
>
>
> On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz <[e-mail]> wrote:
>
> Why not use HTTP CONNECT?  Or rather, it would be helpful to have a
> section on when/why one would do this vs. CONNECT.
>
>
>
> On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <[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]> 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
> Status:         https://datatracker.ietf.org/
> doc/draft-friel-tls-over-http/
> Htmlized:       https://tools.ietf.org/html/draft-friel-tls-over-http-00
> Htmlized:       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.
>
> The IETF Secretariat
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
>
>
>
>
>
>
>
>
>