Re: [TLS] TLS Charter Revision

[Sean Turner <[e-mail]>]

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 <[e-mail]> wrote:

> 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: 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
>> 
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> -- 
> email: 
> [e-mail]
>  | Skype: rstruik
> cell: [phone] | US: [phone]
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls