Re: [TLS] TLS Charter Revision

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 10 December 2013 10:14 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 331771A1F3D for <tls@ietfa.amsl.com>; Tue, 10 Dec 2013 02:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 xrkVyVf1ECmA for <tls@ietfa.amsl.com>; Tue, 10 Dec 2013 02:14:13 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 789EC1AD944 for <tls@ietf.org>; Tue, 10 Dec 2013 02:14:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A420BE5D; Tue, 10 Dec 2013 10:14:07 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAf0L+w4sprp; Tue, 10 Dec 2013 10:14:07 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07B22BE54; Tue, 10 Dec 2013 10:14:07 +0000 (GMT)
Message-ID: <52A6E96F.1080808@cs.tcd.ie>
Date: Tue, 10 Dec 2013 10:14:07 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Yoav Nir <synp71@live.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <A86275E1-44B7-444B-9E50-FD6DE5CC5190@cisco.com> <7e7fa1fa-f889-4f3a-907d-670bb218d952@email.android.com> <BLU0-SMTP1748FC77F29BBC51C22D77EB1D20@phx.gbl>
In-Reply-To: <BLU0-SMTP1748FC77F29BBC51C22D77EB1D20@phx.gbl>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS Charter Revision
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: Tue, 10 Dec 2013 10:14:22 -0000

On 12/10/2013 09:24 AM, Yoav Nir wrote:
> Hi Stephen
> 
> I suggest "better confidentiality". "Privacy" applies to humans, not 
> machines. I don't think it's appropriate for a machine-2-machine 
> protocol like TLS.

A reasonable point. However by privacy I was also trying to
include any reasonable steps that can be taken e.g. to make
traffic analysis harder, without implying that that would
be higher priority than e.g. performance though. For example
Alfredo's ideas on padding (or similar) could be built in
to the TLS1.3 application data protection and that could
be well worth while.

There could also be aspects related to how identifying
different protocol elements might be, where different design
decisions (with about the same costs) could be made if the
WG does or doesn't consider privacy.

I'd have no objection if the charter didn't use the term
privacy but it seems like a useful shorthand to save having to
try break it out into the various reasonable bits that could
be done here.

But yeah maybe it'd be better qualified e.g. to something
like "The WG will consider the privacy implications of
TLS1.3 and where possible (balancing with other requirements)
will aim to make TLS1.3 more privacy-friendly, e.g. via more
consistent application traffic padding, more considered use
of long term identifying values, etc."

To be clear: I'm not asking that TLS1.3 become Tor:-)

S.

> 
> On 10/12/13 10:59 AM, Stephen Farrell wrote:
>> Hi Joe
>> 
>> Wouid it be reasonable to add a "better privacy" goal for the tls
>> 1.3 work?
>> 
>> Ta S
>> 
>> 
>> "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> wrote:
>>> Updated Charter text based on the discussion so far is below.
>>> Changes:
>>> 
>>> 
>>> 1. Fixed typos 2. Third bullet to "Update record payload
>>> protection cryptographic mechanisms and algorithms to address
>>> known weaknesses in the CBC block cipher modes and to replace
>>> RC4."
>>> 
>>> Thanks,
>>> 
>>> Joe
>>> 
>>> The TLS (Transport Layer Security) working group was established
>>> in 1996 to standardize a 'transport layer' security protocol.
>>> The basis for the work was SSL (Secure Socket Layer) v3.0.  The
>>> TLS working group has completed a series of specifications that
>>> describe the TLS protocol v1.0, v1.1, and v1.2 and DTLS (Datagram
>>> TLS) v1.2 as well as extensions to the protocols and
>>> ciphersuites.
>>> 
>>> The primary purpose of the working group is to develop (D)TLS
>>> v1.3.  Some of the main design goals are as follows, in no
>>> particular order:
>>> 
>>> o Develop a mode that encrypts as much of the handshake as is
>>> possible to reduce the amount of observable data to both passive
>>> and active attackers.
>>> 
>>> o Develop modes to reduce handshake latency, which primarily 
>>> support HTTP-based applications, aiming for one roundtrip for a
>>> full handshake and one or zero roundtrip for repeated 
>>> handshakes.
>>> 
>>> o Update record payload protection cryptographic mechanisms and
>>> algorithms to address known weaknesses in the CBC block cipher
>>> modes and to replace RC4.
>>> 
>>> o Reevaluate handshake contents, e.g.,: Is time needed in client
>>> hello?  Should signature in server key exchange cover entire
>>> handshake?  Are bigger randoms required? Should there be distinct
>>> cipher list for each version?
>>> 
>>> A secondary purpose is to maintain previous version of the (D)TLS
>>> protocols as well as to specify the use of (D)TLS,
>>> recommendations for use of (D)TLS, extensions to (D)TLS, and
>>> cipher suites.  However, changes or additions to older versions
>>> of (D)TLS whether via extensions or ciphersuites are discouraged
>>> and require significant justification to be taken on as work
>>> items.
>>> 
>>> With these objectives in mind, the TLS WG will also place a
>>> priority in minimizing gratuitous changes to TLS.
>>> 
>>> Milestone/Dates:
>>> 
>>> 201311 - Out-of-Band Public Key Validation for TLS to IESG 201401
>>> - Secure Password Ciphersuites for TLS to IESG 201404 - TLS ALPN
>>> (Application Layer Protocol Negotiation) Extension to IESG 201411
>>> - (D)TLS 1.3 to IESG 
>>> _______________________________________________ TLS mailing list 
>>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>> 
>> _______________________________________________ TLS mailing list 
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 
>