Subject: Re: [TLS] TLS Charter Revision

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 30 Jan 2014 23:00:38 +0000

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

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 Jan 2014 18:49:18 -0500

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:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Sean Turner <[email-masked]>
Date: Fri, 31 Jan 2014 10:35:58 -0500

Rene,

A couple of people have mentioned the fact that list of objectives is incomplete or they’re worried their issue not being listed means it’s out of scope.  Right now the charter includes the following to address this (at least in my mind) "Some of the main design goals are as follows, in no particular order:”  That list is honestly there to make sure the IESG will be comfortable agreeing to the rechartering.  What I hope will happen is that folks can bring their proposals, they get evaluated, and the WG will use its better judgement about what makes sense to get adopted.

spt

On Jan 30, 2014, at 18:49, Rene Struik <[email-masked]> wrote:

> and at SAC 2010:
> René Struik: Batch Computations Revisited: Combining Key Computations and Batch Verifications. 130-142
> 
> 
> email: 
> [email-masked]
>  | Skype: rstruik