* 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: Roman Danyliw, Benjamin Kaduk | 1996-May-24 —  

2020-01-13 charter

Transport Layer Security (tls)


 Current Status: Active

     Christopher A. Wood <caw@heapingbits.net>
     Joseph A. Salowey <joe@salowey.net>
     Sean Turner <sean+ietf@sn3rd.com>

 Security Area Directors:
     Roman Danyliw <rdd@cert.org>
     Benjamin Kaduk <kaduk@mit.edu>

 Security Area Advisor:
     Benjamin Kaduk <kaduk@mit.edu>

 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

  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

  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:
  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 -