Fwd: Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)

["Eggert, Lars" <[e-mail]>]

No more chasing TLS draft versions.

Lars

> Begin forwarded message:
> 
> From: The IESG <[e-mail]>
> Subject: Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)
> Date: March 21, 2018 at 10:02:02 GMT
> To: "IETF-Announce" <[e-mail]>
> Cc: [e-mail], [e-mail], [e-mail], [e-mail], The IESG <[e-mail]>, [e-mail]
> Reply-To: [e-mail]
> 
> The IESG has approved the following document:
> - 'The Transport Layer Security (TLS) Protocol Version 1.3'
>  (draft-ietf-tls-tls13-28.txt) as Proposed Standard
> 
> This document is the product of the Transport Layer Security Working Group.
> 
> The IESG contact persons are Kathleen Moriarty and Eric Rescorla.
> 
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
> 
> 
> 
> 
> Technical Summary
> 
>   This document specifies version 1.3 of the Transport Layer Security
>   (TLS) protocol.  TLS allows client/server applications to communicate
>   over the Internet in a way that is designed to prevent eavesdropping,
>   tampering, and message forgery.
> 
> Working Group Summary
> 
>  The document is the work product of the members of the TLS
>  WG.  There is strong consensus in the working group for this
>  document.  The area that was most controversial was around
>  the inclusion of a 0-RTT mode that has different security
>  properties than the rest of TLS.  s1.3 lists the major differences
>  from TLS1.2, as agreed by the contributors; we do not think
>  that the RFC needs to list the changes that occurred between
>  each draft.
> 
>  The draft has had 3 WGLCs to address various issues and the
>  chairs assessment was fair in each of these discussions.  At this
>  point there are no known outstanding issue.
> 
>  While I personally do not agree with inclusion of 0-RTT because
>  there are bound to be successful attacks against the mitigations
>  in the future, I do agree with the chair's assessment of the WG
>  consensus and am pleased with the additional text on mitigating
>  the associated risks with 0-RTT.
> 
> Document Quality
> 
>  There are over 10 interoperable implementations of the
>  protocol from different sources written in different
>  languages.  The major web browser vendors and TLS
>  libraries vendors have draft implementations or have
>  indicated they will support the protocol in the future.  In
>  addition to having extensive review in the TLS working
>  group, the protocol has received unprecedented security
>  review by the academic community.  Several TRON (TLS
>  Ready or Not) conferences were held with academic
>  community to give them a chance to present their
>  findings for TLS.  This has resulted in improvements to
>  the protocol.  There was also much consideration and
>  discussion around any contentious points, resolved through
>  polls and working group last calls.
> 
>  Please note that ID-nits complains about the obsoleted/
>  updated RFCs not being listed in the abstract. This is
>  intentional because the abstract is now a concise and
>  comprehensive overview and is free form citations, as
>  per RFC7322.
> 
> Personnel
> 
>   The Document Shepherd is Sean Turner.
>   The responsible AD is Kathleen Moriarty.
> 
>   The IANA Expert(s) for the registries
>   in this document are
>     Yoav Nir <[e-mail]>,
>     Rich Salz <[e-mail]>, and
>     Nick Sullivan <[e-mail]> .
> 
> IANA Note
> 
>  This document requests the creation of the TLS SignatureScheme
>  Registry with values assigned via Specification Required [RFC8126].
> 
>  This document requests the reference for several registries be
>  updated to point to this document.  The registries include:
>  - TLS Cipher Suite Registry, updated via via Specification Required [RFC8126]
>  - TLS ContentType Registry, future values allocated via Standards Action [RFC8126]
>  - TLS Alert Registry, future values allocated via Standards Action [RFC8126]
>  - TLS HandshakeType Registry, future values allocated via Standards Action [RFC8126]
>  - TLS ExtensionType Registry, the policy is changed in ietf-tls-iana-registry-updates and this will be reflected in version 25 of the draft
> 
> 
> RFC Editor Note
> 
> Please ensure a reference is added prior to final publication for the
> text added in section
> E.6. PSK Identity Exposure
> of draft-ietf-tls-tls13
>