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

Alex C <immibis@gmail.com> Tue, 07 November 2017 09:26 UTC

Return-Path: <immibis@gmail.com>
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 42D1D13FD50 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 01:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XDM6hKg_qIk5 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 01:26:39 -0800 (PST)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 0808913FD42 for <tls@ietf.org>; Tue, 7 Nov 2017 01:21:39 -0800 (PST)
Received: by mail-vk0-x231.google.com with SMTP id o145so110513vkd.0 for <tls@ietf.org>; Tue, 07 Nov 2017 01:21:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7eMPjcwHFVFpmBpSqU+ic3l/iuejDyTZPYkc5wNRQAE=; b=EmlU/klpPITM6GI7NpjuUOVODJKoNPsLU8FVObFPdskUU3GV/HGwKqNwb+qRSjkTNo g97vG3ETUu9DpSaVGWWN7hNPH6i1cY7Z3vrVKd8Fv6ZYuWPWBgN78vYhq8FVfYqfajuT NnVe2IKVrOI7TbzVOkvxpe0yBgNWMFK1nu20Ap/jlT73UJAa192View1jNGj7rM8YUjz OPhvvpqtEuMqqqQB+OaZSE+VT0Hg75oTE1PJhBGQ3lBtHkOi56B0gj8Kg1J1E0sU7zdU xNNOtibetlhMTQm5ZxKA4yJg3y+CBcBr80PlNjSKReR7ONWGsay/swCNw5zKoAlrafij S/eg==
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=7eMPjcwHFVFpmBpSqU+ic3l/iuejDyTZPYkc5wNRQAE=; b=bwJBQyttkHrCQebAyVs84snOjynG5/Fye7M0SQhRmXL31FonSsQrwoXY57cij4VehH 3TA5Fu0Wj3CwNkM67keVtvA+WGTCTbPjSkgwCqRQGJzKUXRmJajeKEMbe6hetAK1kgA5 MkvBiPN4HajclS2PtQO7oHsFkhdsjm4Bs7+XS/wqO41J0pd8vYf/z0yhu7kvY2MZoIPf VFKedFuFWwA2sdyEp5HLtnDEEqeqnhoeNDMzKdyVpzrTrV+ruc4K7AkOKAPbli6c+Lla 87m1FI3rQ2PhZuYSdEzyeqvs1vlArGPXwTT0OOdY4j97NMzgzGje/jR6mb255BVAuKbe OCrw==
X-Gm-Message-State: AJaThX6afNGFKxWEstRe76Kf6J2mxXwybr7wgyCDmOLZDP7IXXRsY99W U53uLdZg4NkcFzmuEfIkRmeQOQca8tKD9/PNAlY=
X-Google-Smtp-Source: ABhQp+TGIHmC1Nep45aA6LbVoAOcKafEUPZuJX2c7ZnHr65EaUT3DGmPvVCilbCEyb9UBSDlWfL9fC3Fyus6BRGm0Xo=
X-Received: by 10.31.53.204 with SMTP id c195mr14460203vka.97.1510046498061; Tue, 07 Nov 2017 01:21:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.67 with HTTP; Tue, 7 Nov 2017 01:21:37 -0800 (PST)
In-Reply-To: <CAL02cgRS715Vc+4_QNDSNBW8LP1f-Rmp0FW9W_pyHHpAnkX7Sg@mail.gmail.com>
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <CAL02cgRS715Vc+4_QNDSNBW8LP1f-Rmp0FW9W_pyHHpAnkX7Sg@mail.gmail.com>
From: Alex C <immibis@gmail.com>
Date: Tue, 07 Nov 2017 22:21:37 +1300
Message-ID: <CAMqknA6-+=W8j77xZ80M8Y+bz3V+VLUDOYjgK2vA0=HLHk7k2w@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114476081c843c055d6119b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xn-Le7-p1sGKvreSHVBaFQ2tvxQ>
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: Tue, 07 Nov 2017 09:26:43 -0000

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