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

Yoav Nir <ynir.ietf@gmail.com> Tue, 07 November 2017 15:49 UTC

Return-Path: <ynir.ietf@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 9532213401E for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 07:49:39 -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 0t-skS1DIlrN for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 07:49:37 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 13A0A13FFB6 for <tls@ietf.org>; Tue, 7 Nov 2017 07:43:31 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id t139so4848359wmt.1 for <tls@ietf.org>; Tue, 07 Nov 2017 07:43:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7T8sKyXZPg5++o6jgL7rP80pNP9pm1DlW5x8H1GiS2Y=; b=vKpNu4TresyZsdMyRVgbQc989fbDjbyMSw/grfjYqzt3XjL2v9ej0lCXxrkvRHiiTb hYKm6mU7FfYDjb+42QaewdElA6SB9ehjVdFQLjTWAnER1fKDlqTJCb26HnAjCS2aDrbp 9gU7YQ7rqYLMWl7EZ3S55f9lkjxzVtnHeUCxkFXfWAVNSH0pKYmFyFPVDiRoYTEsZvFl RjZYxApubpun5eo+WjeVeG/bvO227VBKdCK19EzPP4C7pf5UIheXhxFxxYJ2f6Pvivh/ Zhh4+VlUvwUvL3qllOlPpQ1hE9M96w7hKxROipAiL3g5jXc5w+ojkp2MdeaMO9SNH+MW Mgig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7T8sKyXZPg5++o6jgL7rP80pNP9pm1DlW5x8H1GiS2Y=; b=Apz5NOdEcyqm4R5giDWQJXW5eT5cRubKKw3keZ5DozdRAoYZExd3EoK1r8UEdvBgAV LpAdiIKsQ0yaPhZgWOMGxHWKSh6V32Hv173khVm2dxZtOglwBwVqVF1BxahlKp4JEg+P GfVAs58VRVipXj8efX9oPhgoOcgtG/Wtu1D3+To/flQHsSPdjuNFkC7x7+akfYgcQTBm 9JkCfuZKxTEWV8h+QeSbbLO38a7/HN2sm9Gcr6hEmrWxbqag7J+yfRP/kj2Mj7MF0kbo fXTh1njPUNCBWROEgZpU+DhSx9OcSUKC3AH81rCgZ1EItThhFHnq5lTXbP0ojiRzD9Fv izxQ==
X-Gm-Message-State: AJaThX4z5eaecKZ9Igx4dGOhhlN0U5VYUK369r6KgT164LFAoGi90yS9 gkiqxhMZfKhXunMZIFe5Lxg=
X-Google-Smtp-Source: ABhQp+Q0GEutTEsqkNowpupGDYElcxB5fyB334uxKFPrQxiiPLbMZD9OSA79M5z8N3HqAkE/qMyrnQ==
X-Received: by 10.28.18.144 with SMTP id 138mr1607143wms.135.1510068984831; Tue, 07 Nov 2017 07:36:24 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p79sm2899286wmf.43.2017.11.07.07.36.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 07:36:24 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <A5DA4601-DC89-4847-9D7A-87C5CBCB42FD@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_16B1CC4F-EDCC-4C02-AF6A-FB7830FF6ED1"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Tue, 7 Nov 2017 17:36:21 +0200
In-Reply-To: <da4504a1-f868-bf66-1f28-2b7716207d07@gmx.net>
Cc: Alex C <immibis@gmail.com>, Richard Barnes <rlb@ipv.sx>, "<tls@ietf.org>" <tls@ietf.org>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <CAL02cgRS715Vc+4_QNDSNBW8LP1f-Rmp0FW9W_pyHHpAnkX7Sg@mail.gmail.com> <CAMqknA6-+=W8j77xZ80M8Y+bz3V+VLUDOYjgK2vA0=HLHk7k2w@mail.gmail.com> <da4504a1-f868-bf66-1f28-2b7716207d07@gmx.net>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dHuO7KxqmFjWaERxAoW_xKA13CM>
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 15:49:40 -0000

Hi, Hannes.

I think it makes sense if the middlebox (whether a TLS proxy or a phone) cannot perform a MitM attack against the internal TLS. This can be achieved by having separate trust anchors for the application vs the ones used for HTTPS, specifically not including any “proxy CA certificate”.

Yoav

> On 7 Nov 2017, at 17:15, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> FWIW: I can tell you what the threat model was with the layered TLS work.
> 
> Let me give you a very specific example. Imagine a Bluetooth Low Energy
> device that communicates via a phone to a cloud-based service. The
> communication from the phone to the cloud uses HTTPS. The communication
> from the BLE device to the phone uses ordinary BLE
> services/characteristics.
> 
> The Layered TLS/application layer TLS would in this case run from the
> BLE device all the way to the cloud-based service at the application layer.
> 
> This allows us to provide end-to-end security across a proxy (in this
> case the phone) and independent of the underlying protocols.
> 
> Does this make sense?
> 
> Ciao
> Hannes
> 
> 
> On 11/07/2017 10:21 AM, Alex C wrote:
>> 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
>> <mailto:rlb@ipv.sx <mailto: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 <mailto:internet-drafts@ietf.org>
>>    <mailto:internet-drafts@ietf.org <mailto: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 <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt>
>>        <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt>>
>>        Status:
>>         https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/>
>>        <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/>>
>>        Htmlized:
>>         https://tools.ietf.org/html/draft-friel-tls-over-http-00 <https://tools.ietf.org/html/draft-friel-tls-over-http-00>
>>        <https://tools.ietf.org/html/draft-friel-tls-over-http-00 <https://tools.ietf.org/html/draft-friel-tls-over-http-00>>
>>        Htmlized:
>>         https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00>
>>        <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 <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 <http://tools.ietf.org/> <http://tools.ietf.org <http://tools.ietf.org/>>.
>> 
>>        The IETF Secretariat
>> 
>> 
>> 
>>    _______________________________________________
>>    TLS mailing list
>>    TLS@ietf.org <mailto:TLS@ietf.org> <mailto:TLS@ietf.org <mailto:TLS@ietf.org>>
>>    https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>>    <https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>