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

[Richard Barnes <[e-mail]>]

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.  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.

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.)

--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
>>>>>
>>>>>
>>>>
>>>
>>
>