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

[Ben Schwartz <[e-mail]>]

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.


>   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>.  (Or just document that reverse proxies
and frameworks ought to do something reasonable with 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.

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.


>
>
> --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/d
>>>>>>> raft-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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>