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

Richard Barnes <rlb@ipv.sx> Mon, 30 October 2017 22:37 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48804C23A for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 15:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk8Bq05LIN1Q for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 15:37:42 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB8713942C for <tls@ietf.org>; Mon, 30 Oct 2017 15:37:41 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id n74so10927208wmi.1 for <tls@ietf.org>; Mon, 30 Oct 2017 15:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cn/wRSuJsf/e/0fos53q6+hDYbNTTf7PlpygzzMldis=; b=A/nwUfOu9mWf32HeJYMxCT/R/z1Q9c3UcxWsufM/vi2A+6Nrwu9ULxMeQtoGcCrcvO XVZbFpfif4N/SWuxMtRYRVgJUwb8UBpUHLirSOJ1D5Llr+1MwrJUuKc3DXuiu5LKo9bP vuKiyfBWl6CzPWZNEV8QYJUCtYMAVjCVLicD2Absp1mhCghnWoBf/T2it8c1CzZIvZ5h /RF/41dTZj2ZZTzbKyCpRiBFZxVWR/eaW87RozEwJ0nQAr6vLqUuNSDS2eOUkZIIeWt7 5Iem6aqh28fipH3rrMmeGNoZRfJatbyWC8tdW1xi+NWWwddaXBbwy66vY7s2ZZhD111D 1PqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cn/wRSuJsf/e/0fos53q6+hDYbNTTf7PlpygzzMldis=; b=dfACwK7liBIOVarMPA12BoNiVrXC3oTd3n+vDFDU7CU4c33cHmtA6R2oF1g5XXjrZC wvx887Tc57LFKOXIBYrY5cYVjLgcEWBUViOgQ5CzfnoRgwZX9l3s+xTrfRz5nypdybLN sjD++VOGwimKq4pYelhrcVXusUzWbiKa3e+JqPnSbB0TY2jlwqAiPbDN5edqK8Md0Q5W 2FUVjhmAV98cVs1pyv2RO1MKFY7NMgyu05Pz4887Q1LNksgA9gLClAyD3+B9MyNVHXcS Xi2JONvWDQ6pEbA9sshBVBtJG8m4z9+rRTLMa4nQPFJF03kOZkRF+SDvwzg1BNgu7Y+O jh6A==
X-Gm-Message-State: AMCzsaXHRG4/OBJ+yh6VCVYuUFS+Ht/12g1DIXNdr3TmoTH7YmoHYA7k l83UfRr0lyIFusut6h2byfPRQD+ngn9oatUSkaz4WA==
X-Google-Smtp-Source: ABhQp+T8G6PGHKZYTLmPb82guVY13532Iur4ILgdrx7E5dHVZCUr39vl1DwQulPEbul1Fp0RS6PhbG1+n92u2ZNQy/I=
X-Received: by 10.28.21.10 with SMTP id 10mr161388wmv.41.1509403060374; Mon, 30 Oct 2017 15:37:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 15:37:39 -0700 (PDT)
In-Reply-To: <CAHbrMsDMdjkffwqE+CeVfHBcU1gnxW3rpOmiitM3fCMyrTye0g@mail.gmail.com>
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <CAL02cgRS715Vc+4_QNDSNBW8LP1f-Rmp0FW9W_pyHHpAnkX7Sg@mail.gmail.com> <CAHbrMsDMdjkffwqE+CeVfHBcU1gnxW3rpOmiitM3fCMyrTye0g@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 30 Oct 2017 18:37:39 -0400
Message-ID: <CAL02cgTwWB_w4+j=8RS=1ZfxNkLE0OeKivrjz33oBamJyD_tbQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1145a9323ca0f4055ccb4971"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CIaAw9P5L9cnVGltxe78yM3LDY0>
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 22:37:44 -0000

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 <bemasc@google.com> 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 <rlb@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-drafts@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
>>> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>