Re: [TLS] TLS Charter Revision

Rene Struik <rstruik.ext@gmail.com> Thu, 30 January 2014 23:50 UTC

Return-Path: <rstruik.ext@gmail.com>
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 692651A04EE for <tls@ietfa.amsl.com>; Thu, 30 Jan 2014 15:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-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 UrO3BCuj9lfK for <tls@ietfa.amsl.com>; Thu, 30 Jan 2014 15:50:05 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 93A211A04ED for <tls@ietf.org>; Thu, 30 Jan 2014 15:49:32 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id lx4so3939443iec.41 for <tls@ietf.org>; Thu, 30 Jan 2014 15:49:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=TdCDO6OEYMmAXJ7by97kN/s0aKVVvnbDZ2G6QriX8co=; b=utBAVxjH2rZbHEEhd6kM6UxRTsluw4MeL6MsKX6ApfbKbAMkTJQb4/CazfUB1ZukVd DMEOLP2+M2X9HsedniPpt2Ll1eqpQYKs+yn1rW00a4drPSlIBmiKjYBMx9qie0AKOHnJ 2Pu1+vNLrMi50BnZ3PSjo6k6OusBYiEmmdHwzYO+cKwexKI50UuVCKEEJTFgqKHZoqp1 B8siJlae4eBnY7HmLzn57ugvMQhgAaLOKbcENUZrVj7VOv5uEWCrLa9HIWqlZhVtWxq8 n+oUfnVb/8Eu+aCECKXk/2B1N32EUNJjaSkVJfhY2bcDkiHoimALvS9bAy5mFjY+cdAu CDgA==
X-Received: by 10.51.17.101 with SMTP id gd5mr16938137igd.25.1391125769125; Thu, 30 Jan 2014 15:49:29 -0800 (PST)
Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id x13sm58251240igp.2.2014.01.30.15.49.27 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jan 2014 15:49:28 -0800 (PST)
Message-ID: <52EAE4FE.2060503@gmail.com>
Date: Thu, 30 Jan 2014 18:49:18 -0500
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <CACsn0ckzA9hd3+zTH5FNNBbPAQqUqaXD8_Z35a8vKEG6WjXbTg@mail.gmail.com> <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com> <CAOdDvNqQ_QaX4QjweRWuAQ=P83fXhew_diEWOp0Rq0amwW3OAQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E4675283@USMBX1.msg.corp.akamai.com> <CACsn0c=Fv+V39G-2695fdbRKKq44rAFLpL11UeqcCUaL_YU42w@mail.gmail.com> <568e68cbc61344fc8ad91dcd238a5f4b@BY2PR03MB074.namprd03.prod.outlook.com> <F182EA8A-51DC-4803-B8C0-8B4DDF6FDDCD@cisco.com>
In-Reply-To: <F182EA8A-51DC-4803-B8C0-8B4DDF6FDDCD@cisco.com>
Content-Type: multipart/alternative; boundary="------------040905070506090407000204"
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: Thu, 30 Jan 2014 23:50:16 -0000

Hi Joe:

Thanks for forwarding this to the group.

I would recommend adding one more objective to the list: improving the efficiency of the handshake protocol, even in scenarios where one does not try and cut down the number of protocol flows, e.g., by exploiting parallel vs. serial key computation and combined key computation and certificate verification techniques.

Some of this was presented at the CFRG meeting in Paris, France, March 28, 2012, see Slide 6 of
http://www.ietf.org/proceedings/83/slides/slides-83-cfrg-5.pdf
and at SAC 2010:René Struik  <http://www.informatik.uni-trier.de/%7Eley/pers/hd/s/Struik:Ren=eacute=>:  Batch Computations Revisited: Combining Key Computations and Batch Verifications.  130-142

This would be especially useful in highly constrained settings, where any computational efficiency gains are highly desirable.

Suggested additional Charter text:

o Consider other mechanisms to reduce handshake time latency, based on reconsideration of packet processing rules that could facilitate more efficient cryptographic processing, while maintaining or improving current security features.


On 1/30/2014 6:00 PM, Joseph Salowey (jsalowey) wrote:
> I updated the charter based on the list discussion and included it below.  Sean is going to forward this version to the IESG.
>
> Main changes:
>
> 2nd bullet: added "The aim is also to maintain current security
> features."
>
> 4th bullet: added "Are
> additional mechanisms needed to prevent version rollback
> needed?"
>
> 6th Bullet: added Stephen's privacy text.
>
> Cheers,
>
> 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.   The aim is also to maintain current security
> features.
>
> 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?  Are
> additional mechanisms needed to prevent version rollback
> needed?
>
> o 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.
>
> 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:
>
> 201404 - CBC Fixes to IESG
> 201405 - RC4 replacement to IESG
> 201411 - (D)TLS 1.3 to IESG
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363