Subject: Re: WG Action: Rechartered Transport Layer Security (tls)

From: Farooq247 <[email-masked]>
Date: Fri, 7 Feb 2014 18:05:03 +0000

Oh no rechartered - please keep me informed.

with best

Hansen

On 7 February 2014 18:02, The IESG <[email-masked]> wrote:

> The Transport Layer Security (tls) working group in the Security Area of
> the IETF has been rechartered. For additional information please contact
> the Area Directors or the WG Chairs.
>
> Transport Layer Security (tls)
> ------------------------------------------------
> Current Status: Active WG
>
> Chairs:
>   Eric Rescorla <[email-masked]>
>   Joseph Salowey <[email-masked]>
>   Eric Rescorla <[email-masked]>
>
> Technical advisors:
>   Allison Mankin <[email-masked]>
>
> Assigned Area Director:
>   Sean Turner <[email-masked]>
>
> Mailing list
>   Address: [email-masked]
>   To Subscribe: https://www.ietf.org/mailman/listinfo/tls
>   Archive: http://www.ietf.org/mail-archive/web/tls/
>
> Charter:
>
> 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.
>
> Milestones:
>   Jan 2014 - CBC Fixes to IESG
>   May 2014 - RC4 replacement to IESG
>   Nov 2014 - (D)TLS 1.3 to IESG
>
>
>