* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tls Status Pages

Transport Layer Security (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 1996-May-24 —  
Chairs
 
 


2017-03-30 charter

Transport Layer Security (tls)
------------------------------

 Charter

 Current Status: Active

 Chairs:
     Joseph A. Salowey <joe@salowey.net>
     Sean Turner <sean+ietf@sn3rd.com>

 Security Area Directors:
     Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
     Eric Rescorla <ekr@rtfm.com>

 Security Area Advisor:
     Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

 Mailing Lists:
     General Discussion: tls@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/tls
     Archive:            https://mailarchive.ietf.org/arch/browse/tls/

Description of Working Group:

  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 [RFC6101].  The TLS
  working group has completed a series of specifications
  that describe the TLS protocol v1.0 [RFC2246],
  v1.1 [RFC4346], and v1.2 [RFC5346] and DTLS
  (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347]
  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.

Goals and Milestones:
  Done - See RFC 7525 & MTI AEAD algs in TLS1.3     - CBC Fixes to IESG
  Done - See RFC 7465 & RFC 7905     - RC4 replacement to IESG
  Feb 2017 - (D)TLS 1.3 to IESG
  Feb 2017 - Move ECC-based CS to Standards Track
  May 2017 - DANE Record and DNSSEC Authentication Chain Extension for TLS to IESG
  Aug 2017 - DTLS1.3 to IESG


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/tls/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -