• Settings
• New Account
• Options
• Working Groups
• • Applications
    • appsawg — Applications Area Working Group
    • calext — Calendaring Extensions
    • core — Constrained RESTful Environments
    • dmarc — Domain-based Message Authentication, Reporting & Conformance
    • eppext — Extensible Provisioning Protocol Extensions
    • httpbis — Hypertext Transfer Protocol
    • hybi — BiDirectional or Server-Initiated HTTP
    • json — JavaScript Object Notation
    • paws — Protocol to Access WS database
    • precis — Preparation and Comparison of Internationalized Strings
    • scim — System for Cross-domain Identity Management
    • tzdist — Time Zone Data Distribution Service
    • urnbis — Uniform Resource Names, Revised
    • uta — Using TLS in Applications
    • websec — Web Security
    • weirds — Web Extensible Internet Registration Data Service
  • General
    • ianaplan — Planning for the IANA/NTIA Transition
  • Internet
    • 6lo — IPv6 over Networks of Resource-constrained Nodes
    • 6man — IPv6 Maintenance
    • 6tisch — IPv6 over the TSCH mode of IEEE 802.15.4e
    • ancp — Access Node Control Protocol
    • dhc — Dynamic Host Configuration
    • dmm — Distributed Mobility Management
    • dnssd — Extensions for Scalable DNS Service Discovery
    • dprive — DNS PRIVate Exchange
    • hip — Host Identity Protocol
    • homenet — Home Networking
    • intarea — Internet Area Working Group
    • l2tpext — Layer Two Tunneling Protocol Extensions
    • lisp — Locator/ID Separation Protocol
    • lwig — Light-Weight Implementation Guidance
    • mif — Multiple Interfaces
    • mip4 — Mobility for IPv4
    • multimob — Multicast Mobility
    • netext — Network-Based Mobility Extensions
    • ntp — Network Time Protocol
    • pcp — Port Control Protocol
    • savi — Source Address Validation Improvements
    • softwire — Softwires
    • sunset4 — Sunsetting IPv4
    • tictoc — Timing over IP Connection and Transfer of Clock
    • trill — Transparent Interconnection of Lots of Links
  • Ops & Mgmt
    • anima — Autonomic Networking Integrated Model and Approach
    • bmwg — Benchmarking Methodology
    • dime — Diameter Maintenance and Extensions
    • dnsop — Domain Name System Operations
    • eman — Energy Management
    • grow — Global Routing Operations
    • ipfix — IP Flow Information Export
    • lime — Layer Independent OAM Management in the Multi-Layer Environment
    • lmap — Large-Scale Measurement of Broadband Performance
    • mboned — MBONE Deployment
    • netconf — Network Configuration
    • netmod — NETCONF Data Modeling Language
    • opsawg — Operations and Management Area Working Group
    • opsec — Operational Security Capabilities for IP Network Infrastructure
    • radext — RADIUS EXTensions
    • v6ops — IPv6 Operations
    • wpkops — Web PKI OPS
  • RAI
    • avtcore — Audio/Video Transport Core Maintenance
    • avtext — Audio/Video Transport Extensions
    • bfcpbis — Binary Floor Control Protocol Bis
    • clue — ControLling mUltiple streams for tElepresence
    • codec — Internet Wideband Audio Codec
    • cuss — Call Control UUI Service for SIP
    • dart — DiffServ Applied to Real-time Transports
    • dispatch — Dispatch
    • drinks — Data for Reachability of Inter/tra-NetworK SIP
    • ecrit — Emergency Context Resolution with Internet Technologies
    • insipid — INtermediary-safe SIP session ID
    • mmusic — Multiparty Multimedia Session Control
    • p2psip — Peer-to-Peer Session Initiation Protocol
    • payload — Audio/Video Transport Payloads
    • rtcweb — Real-Time Communication in WEB-browsers
    • salud — Sip ALerting for User Devices
    • sipcore — Session Initiation Protocol Core
    • siprec — SIP Recording
    • soc — SIP Overload Control
    • stir — Secure Telephone Identity Revisited
    • stox — SIP-TO-XMPP
    • straw — Sip Traversal Required for Applications to Work
    • webpush — Web-Based Push Notifications
    • xmpp — Extensible Messaging and Presence Protocol
    • xrblock — Metric Blocks for use with RTCP's Extended Report Framework
  • Routing
    • bess — BGP Enabled Services
    • bfd — Bidirectional Forwarding Detection
    • ccamp — Common Control and Measurement Plane
    • forces — Forwarding and Control Element Separation
    • i2rs — Interface to the Routing System
    • idr — Inter-Domain Routing
    • isis — IS-IS for IP Internets
    • l2vpn — Layer 2 Virtual Private Networks
    • manet — Mobile Ad-hoc Networks
    • mpls — Multiprotocol Label Switching
    • nvo3 — Network Virtualization Overlays
    • ospf — Open Shortest Path First IGP
    • pals — Pseudowire And LDP-enabled Services
    • pce — Path Computation Element
    • pim — Protocol Independent Multicast
    • pwe3 — Pseudowire Emulation Edge to Edge
    • roll — Routing Over Low power and Lossy networks
    • rtgwg — Routing Area Working Group
    • sfc — Service Function Chaining
    • sidr — Secure Inter-Domain Routing
    • spring — Source Packet Routing in Networking
  • Security
    • abfab — Application Bridging for Federated Access Beyond web
    • ace — Authentication and Authorization for Constrained Environments
    • dane — DNS-based Authentication of Named Entities
    • dice — DTLS In Constrained Environments
    • httpauth — Hypertext Transfer Protocol Authentication
    • ipsecme — IP Security Maintenance and Extensions
    • jose — Javascript Object Signing and Encryption
    • kitten — Common Authentication Technology Next Generation
    • mile — Managed Incident Lightweight Exchange
    • oauth — Web Authorization Protocol
    • sacm — Security Automation and Continuous Monitoring
    • tls — Transport Layer Security
    • trans — Public Notary Transparency
  • Transport
    • alto — Application-Layer Traffic Optimization
    • aqm — Active Queue Management and Packet Scheduling
    • cdni — Content Delivery Networks Interconnection
    • conex — Congestion Exposure
    • dtn — Delay/Disruption Tolerant Networking
    • ippm — IP Performance Metrics
    • mptcp — Multipath TCP
    • nfsv4 — Network File System Version 4
    • ppsp — Peer to Peer Streaming Protocol
    • rmcat — RTP Media Congestion Avoidance Techniques
    • storm — STORage Maintenance
    • taps — Transport Services
    • tcpinc — TCP Increased Security
    • tcpm — TCP Maintenance and Minor Extensions
    • tram — TURN Revised and Modernized
    • tsvwg — Transport Area Working Group
• Active WGs
• Active RGs
• Chartering
• BoFs
• Concluded
• Non-WG Lists
• Drafts & RFCs
• Document search:
• Streams:
  IAB IRTF ISE
• Submit a draft
• Sign in to track drafts
• Meetings
• Agenda
• Materials
• Past Proceedings
• Upcoming
• Session Requests
• Other Documents
• IPR Disclosures
• Liaison Statements
• IESG Agenda
• Related Sites
• Main IETF site
• IETF tools
• IAB
• RFC Editor
• IASA/IAOC/Trust
• IANA
• IRTF

Transport Layer Security (tls)

Charter for 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.

Milestones