IETF Logo Mail Archive

Re: [TLS] Encryption of TLS 1.3 content type

Alfredo Pironti <alfredo@pironti.eu> Fri, 08 August 2014 10:25 UTC

Return-Path: <alfredo@pironti.eu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59D1B28D4 for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 03:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 gh0jU6eLPTVK for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 03:25:53 -0700 (PDT)
Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC511B287B for <tls@ietf.org>; Fri, 8 Aug 2014 03:25:52 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id eb12so3920678oac.3 for <tls@ietf.org>; Fri, 08 Aug 2014 03:25:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bH1Kt1T5WGSFtiS1xJeJbUnGWQYNXTzYxetVS9j7M2E=; b=NctBFmpXiSWzjQbHjKY+e6/7JCsfHTfJmg/Q50vXGZAqXdYDTnyeSg3mNPlOHREUeJ Rw5DKOmUnZqFQoU7myWDY59CQbbMq+a4AQ/6w2T0s4+AuqSfZDhdDMg5A9xLoxDRT8gr Iks+9V0AYx2Qh7YXp3g9sSir6lEVUsPhGAimE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=bH1Kt1T5WGSFtiS1xJeJbUnGWQYNXTzYxetVS9j7M2E=; b=MU69ZjI9lb2mKYSA9jYA7ntpJIuqeM8nkvJ0kl+mgMjDlj/W5mzpD2hFRocBe32Oet RoaVR25cthlXiCENAUOcs7lQfjTT+jJxWOyr8TW3oQFSbS16rdsu88GprKEfqiijdTCS aQ6j4Gs2ocV5/h01gLLEtm9XlYH1v5UI1wQUFX1+iiZAWzIlZmCqykCQ+jwYT8TTHgRB 8NkfbL6Pp/ryhEJz43byD3UwPBFT5z8OAJD1wGZpLU+9/r5FivSp9WoOB/UkBPdz/T42 3GduBNyKhEoo3qKXbEqx395EmMo7oWa0rpXBI97bKToEarzF7DzIn+ZfT+GA6uZ/4XCm Dm1A==
X-Gm-Message-State: ALoCoQkgsjQ1hzKB/SOIrmwbOHpvyFtukNgIahmxMHlTqToPg/gXSptpIx0+dI8XUcWAsQr2n+BE
MIME-Version: 1.0
X-Received: by 10.60.63.166 with SMTP id h6mr1818995oes.79.1407493551790; Fri, 08 Aug 2014 03:25:51 -0700 (PDT)
Received: by 10.76.25.42 with HTTP; Fri, 8 Aug 2014 03:25:51 -0700 (PDT)
X-Originating-IP: [2001:660:3013:3:f17e:3914:5512:a96e]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB2448@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C738EFB2448@uxcn10-5.UoA.auckland.ac.nz>
Date: Fri, 08 Aug 2014 12:25:51 +0200
Message-ID: <CALR0uiJWngqL0xuDaYSR+PSTdkVifoH4P07gGaFn_as_3t4_Jg@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c21eae2dad8f05001ba148"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Be09Nv_kQGx0ZTHaY2xGfFd46Ck
Subject: Re: [TLS] Encryption of TLS 1.3 content type
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 08 Aug 2014 10:25:55 -0000

I guess the benefit of encrypting the content type and hiding the message
length are easier to appreciate when both features are deployed together.
Yet, such features can be designed somewhat independently.

I believe TLS holds an amenable place in the network stack where these
traffic analysis countermeasures can be implemented. But, I stress, the
application remains responsible for the privacy policy, and hence how these
TLS features are used.

For example, Tor abandoned doing authentication via TLS renegotiation*
because, among other reasons, "TLS renegotiation to become rarer and rarer
in the wild, making our own use stand out more" [2].
If TLS could be used to disguise, both in content type and in traffic
shape, a renegotiation as normal application data, projects like Tor may
benefit from it.

* see "v2 handshake" vs "v3 handshake" in [1]
[1]
https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt
[2]
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/176-revising-handshake.txt

v2.23.0 | Report a Bug | By Email